Czy obrazki typu jpg/png w tablicy czy tylko nazwy plików trzymać w kolumnie ?

VS2015 C#, SQL Server 2012 Express ma ograniczoną wielkość do 10GB
Problem:
Program ewidencji sprzętu powinien mieć fotki sprzętu.
Czy w tablicy w kolumnie trzymać nazwy plików/obrazków (i w razie potrzeby brać je z folderu z obrazkami) ?
Czy w tablicy trzymać wszystkie obrazki (Image...) ?
Z uwagi na ograniczenia wielkości bazy wydaje mi się, że lepiej obrazki trzymać poza bazą.
Obrazki będą "otwierane" tylko na wyraźne kliknięcie na danym sprzęcie.
Z drugiej strony lista sprzętu z obrazkami byłaby fajna.
Fotka sensowna ma około 200 do 300kB, czyli 3 fotki około 1 MB,
sprzętu u mnie około 120 000 sztuk, to zajmie 120000/3= 40 GB na fotki
Tablica z fotkami zajmie 40GB oj to sporo ... i problem się rozwiązał, tylko zewnętrzne pliki.

Czy ktoś miał podobny problem i jak to rozwiązał ?
Dziękuję

W bazie do tej porty trzymałem tylko linki do obrazków

Fotki serwujesz statycznie (link bezpośredni do systemu plików) - wtedy baza lżejsza a serwis szybszy.
No chyba, że to są jakieś fotki które chcesz udostępniać tylko wybrańcom (np. nieindeksowalne) - to wtedy trzeba serwować aplikacją (aplikacja czyta z dysku i ew. wysyła klientowi).

Podobno trzeba uczyć się od najlepszych / największych

File store. Facebook engineers had a great talk about it. One take away was to know the practical limit of files in a directory.

http://perspectives.mvdirona.com/2008/06/30/FacebookNeedleInAHaystackEfficientStorageOfBillionsOfPhotos.aspx

Z mojej praktyki też trzyma się tylko linki do plików w bazie a pliki na dysku po prostu.

A czy musi to być na M$ SQL (i to w wersji express)? Bo może wymiana bazy na inną, albo postawienie drugiej (bez ograniczeń - np. Postgresa) do trzymania plików rozwiązałoby problem.

W temacie Twojego pytania - zdania są bardzo podzielone i ciężko powiedzieć, która wersja jest lepsza:

Trzymanie w bazie:

• rozmiar bazy rośnie
• wydajność może spadać
• nie ma ryzyka rozjazdu (że np. ścieżka w bazie wskazuje na jakiś plik, którego jednak został z dysku usunięty)
• łatwość przenoszenia/backupu: w razie czego przenosisz bazę, a w niej masz wszystko
• niektórzy twierdzą, że baza potrafi się rozjechać, mogą być problemy/błędy z trzymanymi tam blob'ami
• po skasowaniu trzeba robić vacuum na bazie (ale w sumie to i tak przydaje się czasem bazę odświeżyć, więc nie jest to jakiś wielki problem)

Trzymanie osobno:

• baza nie puchnie
• można pliki backupować jakimiś narzędziami niezależnymi od bazy
• możliwy dostęp do plików z pominięciem bazy
• możliwa większa wydajność - odczyt czy zapis plików nie obciąża bazy
• w przypadku przenosin albo odtwarzania bazy, musisz pamiętać, żeby odtworzyć także strukturę katalogów z danymi

Odpowiadając na Twoje pytanie - jeśli działasz na expressie to zapomnij o blobach, sama baza potrafi dojść do limitu jedynie zapchana danymi. Sam mam w 2 miejscach takie niewielkie ERPy, które działają na M$ express i po kilku latach (ok. 5) działania dochodzą do granic pojemności i za chwile będzie konieczność wykupienia wersji pełnej.

Pracowałem w firmie gdzie duże pliki (1.5G) były trzymane w bazie. Nie jest to dobre rozwiązanie. Niedość że dokładamy kolejną warstwę pośredniczącą to jeszcze usunięcie pliku z systemu plików jest szybkie (tylko odlinkowanie) a usunięcie pliku z bazy danych jest powolne (potem przerabiałem to na asynchroniczne kasowanie)

Też nie polecam w tym przypadku trzymania plików/obrazków w bazie. Miałem do czynienia z systemem, gdzie wszelkie załączniki - zdjęcia, pdfy, listy przewozowe lądowały w bazie. Oczywiście, spowalniało to system (tym bardziej, że serwer nie byl najnowszy). A jeśli w bazie będziesz trzymał tylko nazwy plików/linki, to kwestia przemyślenia jaki będzie do nich dostęp - link do zasobu sieciowego LAN czy po http....

Skoro uzywasz SQL Server to rozważ filestream

Wtedy łączysz wygodę jaką daje trzymanie obrazów w bazie z przechowywaniem ich w systemie plików

My rozwiązaliśmy to w ten sposób, że pliki (akurat u nas są to głownie dokumenty i skany dokumentów) przechowujemy w jako varbinary w osobnych bazach.
Podzieliliśmy sobie bazy po datach, tak, że każda z nich nie przekroczy okolic 500GB. Wszystkie te bazy są spinane przez widok.
Na ten moment przechowujemy ok 12 milionów plików (około 3TB danych) i działa to bardzo sprawnie. Przykładowo wyciągnięcie pliku do podglądu dla usera to kwestia ułamka sekundy.

S3 (lub Min.io jeśli self-hosted) + linki. Z doświadczenia powiem, że najlepsze rozwiązanie.