Siemanko,
aktualnie w projekcie przechowuję tylko nazwę zdjęcia w DB (MSSQL), a w aplikacji pobieram ścieżkę do folderu wwwwroot/... którą sklejam z nazwą zdjęcia i wyświetlam.
Kiedyś na stażu pamiętam że do DB wrzucali zdjęcie jako plik w formacie blob(?). Niestety przy tym nie uczestniczyłem, a później nie miałem okazji z takich rozwiązań korzystać.
Mógłby ktoś mi podesłać ciekawe linki albo mniej więcej opisać jak coś takiego zrobić?
A czy jesteś pewien, że chcesz to trzymać w bazie?
Bo to jest jeden z 3 głównych powodów świętych wojen wśród programistów:
1) C# vs Java
**2) **trzymanie plików na dysku + ścieżka w bazie vs. BLOB
3) spacje vs taby ;)
Rzuć okiem na:
Obiekty BLOB w bazie MS SQL a bezpieczeństwo.
Przechowywanie dużych plików w bazie danych
https://habiletechnologies.com/blog/better-saving-files-database-file-system/
https://dba.stackexchange.com/questions/2445/should-binary-files-be-stored-in-the-database
https://www.quora.com/Is-it-better-to-use-a-BLOB-to-directly-store-images-in-your-MYSQL-database-or-to-store-images-in-a-file-system-where-the-store-path-is-in-the-actual-database
https://stackoverflow.com/questions/13435187/what-is-difference-between-storing-data-in-a-blob-vs-storing-a-pointer-to-a-fi
insert into `pictures` ( `name`, `image` ) values ( "obrazek.jpg", 0xFFFFAAAAFFAFAFAF ... FF )
gdzie kolumna name to string a image to blob.
A może zamiast bloba trzymać jako BASE64 będzie fajniej? :D
Często pliki trzyma się w chmurze np. Amazon S3
Ja może powiem jak to wygląda z mojej perspektywy (przechowywanie dużej ilości pism).
Na ten moment posiadamy około 15 mln dokumentów (od pojedynczych skanów, zdjęć, przez generowane dokumenty, po kilkuset stronicowe dokumentacje), z przyrostem w granicach 150-250k miesięcznie. Do okresu ok. rok temu było to przechowywane na dyskach. Backupy tego trwały dziesiątki godzin (wiele małych plików), dyski rozrastały się coraz bardziej (w pewnym momencie do 7TB).
Jakieś półtora roku temu rozpoczęliśmy proces przenoszenia tego do DB. Podzieliliśmy dokumentację na określone zakresy dat i stworzyliśmy kilka baz dla plików (na ten moment jest ich 11). Wszystko to jest spinane przez tabelę zawierającą informację jaka data leży w jakiej bazie oraz widok agregujący dane ze wszystkich tych baz.
Dla nas przeniesienie się z plikami do DB było genialnym posunięciem. Zyskaliśmy na wydajności, wygodzie. Backupy wykonują się dużo szybciej (lepiej mieć 11 dużych plików niż 15 mln małych). Mega plusem jest tez to, że w przypadku awarii, albo potrzeby odtworzenia jakiś danych można odtworzyć tylko konkretną bazę.
To ja ostatnio usłyszałem o takiej nowości w SQL serwer jak filestream. Nowością bo jest od 2012:)
https://docs.microsoft.com/en-us/sql/relational-databases/blob/filestream-sql-server?view=sql-server-ver15
Natomiast nie używałem tego jeszcze w żadnym systemie z dużą ilością plików.
Przymierzam się sam do wykonania jakichś testów. O tyle lepsze od trzymania w bazie, że jednak nie będzie przyrostu bazy i np. zakupu kolejnej licencji a jednocześnie serwer blokuje dostęp i np. jakiś inny proces nie usunie plików.
Jeżeli chcesz to koniecznie trzymać w MSSQL, to użyj filestream, bloby robione ręcznie nie mają sensu.
Tylko przemyśl, czy jest Ci to potrzebne - jak duże będą te pliki, ile ich będzie, i czy faktycznie trzeba je razem z bazą backupować i odtwarzać.
U nas wszlekie typy zdjec i dokumentow i innych plikow trzymane sa w Azure strage -> Blobs. Jesli plik pot4zebuje polaczyc z jakims dabymi to trzymam adres do bloba w bazie. Ale czestoci gesto jak sa posegregowane w odpowiednie "foldery" to nie ma nawet rakiej potrzeby