Odpowiedzi:
Spójrz na tę odpowiedź:
Przechowywanie obrazów w DB - tak czy nie?
Zasadniczo wpływ na przestrzeń i wydajność może być dość duży, w zależności od liczby użytkowników. Należy również pamiętać, że serwery internetowe są tanie i można łatwo dodać więcej, aby zrównoważyć obciążenie, podczas gdy baza danych jest zwykle najdroższą i najtrudniejszą do skalowania częścią architektury internetowej.
Istnieje kilka przeciwstawnych przykładów (np. Microsoft Sharepoint), ale zazwyczaj przechowywanie plików w bazie danych nie jest dobrym pomysłem.
O ile prawdopodobnie nie piszesz aplikacji komputerowych i / lub z grubsza nie wiesz, ilu użytkowników kiedykolwiek będziesz mieć, ale na czymś tak przypadkowym i nieoczekiwanym, jak publiczna witryna internetowa, możesz zapłacić wysoką cenę za przechowywanie plików w bazie danych.
Jeśli możesz przejść na SQL Server 2008, możesz skorzystać z obsługi FILESTREAM, która zapewnia najlepsze z obu - pliki są przechowywane w systemie plików, ale integracja bazy danych jest znacznie lepsza niż zwykłe przechowywanie ścieżki pliku w polu varchar. Twoje zapytanie może zwrócić standardowy strumień plików .NET, co znacznie upraszcza integrację.
Powiedziałbym, że to zależy od twojej sytuacji. Na przykład pracuję w samorządach lokalnych i mamy wiele zdjęć, takich jak zdjęcia mugowe itp. Nie mamy dużej liczby użytkowników, ale musimy mieć dobre zabezpieczenia i kontrolę wokół danych. Baza danych jest dla nas lepszym rozwiązaniem, ponieważ ułatwia to i nie będziemy mieć problemów ze skalowaniem.
O co tu chodzi?
Nowoczesne DBMS SQL2008 mają różne sposoby radzenia sobie z BLOBami, które nie są tylko przyklejane do nich w tabeli. Oczywiście są plusy i minusy i być może będziesz musiał pomyśleć o tym trochę głębiej.
To interesujący artykuł, napisany przez późnego (?) Jima Graya
Do BLOBa lub nie do BLOBa: duża pamięć obiektów w bazie danych lub systemie plików
Z własnego doświadczenia wiem, że zawsze lepiej jest przechowywać pliki jako pliki. Powodem jest to, że system plików jest zoptymalizowany pod kątem przechowywania plików, podczas gdy baza danych nie. Oczywiście są pewne wyjątki (np. Szeroko zapowiadany system plików MS nowej generacji ma być zbudowany na serwerze SQL), ale generalnie to moja zasada.
Chociaż wydajność jest problemem, myślę, że nowoczesne projekty baz danych znacznie zmniejszyły problem w przypadku małych plików.
Pomijając wydajność, zależy to również od tego, jak ściśle powiązane są dane. Jeśli plik zawiera dane, które są ściśle powiązane z polami bazy danych, to koncepcyjnie należy do niego i może być przechowywany w blobie. Jeśli zawiera informacje, które mogą potencjalnie odnosić się do wielu rekordów lub mogą mieć pewne zastosowanie poza kontekstem bazy danych, to należy do nich poza. Na przykład obraz na stronie internetowej jest pobierany na oddzielne żądanie od strony, która do niego prowadzi, więc może znajdować się na zewnątrz (w zależności od konkretnego projektu i względów bezpieczeństwa).
Nasz kompromis, i nie obiecuję, że jest najlepszy, polegał na przechowywaniu niewielkich plików XML w bazie danych, ale obrazów i innych plików poza nią.
Podjęliśmy decyzję o przechowywaniu jako varbinary dla http://www.freshlogicstudios.com/Products/Folders/, spodziewając się problemów z wydajnością. Mogę powiedzieć, że byliśmy mile zaskoczeni, jak dobrze to wyszło.
Zgadzam się z @ZombieSheep. Jeszcze jedna rzecz - generalnie nie uważam, że bazy danych faktycznie muszą być przenośne, ponieważ brakuje Ci wszystkich funkcji, które zapewnia dostawca DBMS. Myślę, że migracja do innej bazy danych byłaby ostatnią rzeczą, którą należałoby rozważyć. Tylko 0,02 dolara
Narzut związany z koniecznością przeanalizowania obiektu blob (obrazu) w tablicy bajtów, a następnie zapisania go na dysku w odpowiedniej nazwie pliku, a następnie odczytania tego jest wystarczającym uderzeniem, aby zniechęcić Cię do robienia tego zbyt często, zwłaszcza jeśli pliki są raczej wielkie.