To stare pytanie, które znam, ale czy w przypadku SQL Server 2012 można w końcu przechowywać pliki w bazie danych, czy też naprawdę powinny one być przechowywane w systemie plików z tylko odniesieniami do nich w bazie danych?
Jeśli przechowywanie ich w bazie danych jest obecnie uważane za dopuszczalne, jaki jest najskuteczniejszy sposób, aby to zrobić?
Planuję zastosować szyfrowanie, więc doceniam, że przetwarzanie nie będzie błyskawiczne.
Odpowiedzi:
Jest naprawdę dobry artykuł opublikowany przez Microsoft Research zatytułowany To Blob or Not To Blob .
Ich wniosek po wielu testach wydajnościowych i analizach jest następujący:
jeśli twoje zdjęcia lub dokumenty mają zwykle rozmiar poniżej 256 KB, przechowywanie ich w kolumnie VARBINARY bazy danych jest bardziej wydajne
jeśli obrazy lub dokumenty mają zwykle rozmiar powyżej 1 MB, przechowywanie ich w systemie plików jest bardziej wydajne (a dzięki atrybutowi FILESTREAM programu SQL Server 2008 nadal znajdują się pod kontrolą transakcji i stanowią część bazy danych)
Pomiędzy tymi dwoma, w zależności od zastosowania, jest trochę podrzucenia
Jeśli zdecydujesz się umieścić swoje zdjęcia w tabeli SQL Server, zdecydowanie polecam użycie oddzielnej tabeli do przechowywania tych zdjęć - nie przechowuj zdjęcia pracownika w tabeli pracowników - trzymaj je w osobnej tabeli. W ten sposób tabela Pracownik może pozostać szczupła, wredna i bardzo wydajna, zakładając, że nie zawsze musisz wybierać również zdjęcie pracownika w ramach swoich zapytań.
W przypadku grup plików sprawdź pliki i architekturę grup plików, aby uzyskać wprowadzenie. Zasadniczo należy utworzyć bazę danych z oddzielną grupą plików dla dużych struktur danych od samego początku lub dodać dodatkową grupę plików później. Nazwijmy to „LARGE_DATA”.
Teraz, gdy masz nową tabelę do utworzenia, która musi przechowywać kolumny VARCHAR (MAX) lub VARBINARY (MAX), możesz określić tę grupę plików dla dużych danych:
CREATE TABLE dbo.YourTable
(....... define the fields here ......)
ON Data -- the basic "Data" filegroup for the regular data
TEXTIMAGE_ON LARGE_DATA -- the filegroup for large chunks of data
Zapoznaj się z wprowadzeniem MSDN dotyczącym grup plików i baw się nim!
VARBINARY(MAX)w oddzielnej grupie plików, jeśli masz oddzielną tabelę „plików”, czy po prostu przechowujesz tę całą tabelę w oddzielnej grupie plików, czy też przechowujesz dane „meta” pliku w standardowych grupach plików i po prostu przechowujesz VARBINARY(MAX)w nowa grupa plików?
FILETABLEfunkcji w SQL Server 2012? Tam tylko metadane dotyczące pliku są przechowywane w SQL Server (podobnie jak w przypadku FILESTREAM) - rzeczywisty plik (bajty, które go tworzą) są przechowywane poza bazą danych, na dysku twardym
Jest nadal ma prostej odpowiedzi. To zależy od twojego scenariusza. MSDN zawiera dokumentację, która pomoże Ci podjąć decyzję.
Są tu omówione inne opcje. Zamiast przechowywać w systemie plików bezpośrednio lub w BLOB-ie, możesz użyć FileStream lub File Table w SQL Server 2012. Korzyści z File Table wydają się oczywiste (ale przyznaję, że nie mam z nimi osobistego doświadczenia .)
Artykuł jest zdecydowanie wart przeczytania.
Możesz poczytać na FILESTREAM . Oto kilka informacji z dokumentów, które powinny pomóc w podjęciu decyzji:
Jeśli poniższe warunki są spełnione, rozważ użycie FILESTREAM:
- Średnio przechowywane obiekty są większe niż 1 MB.
- Szybki dostęp do odczytu jest ważny.
- Tworzysz aplikacje, które używają warstwy środkowej dla logiki aplikacji.
W przypadku mniejszych obiektów przechowywanie varbinary (max) BLOB w bazie danych często zapewnia lepszą wydajność przesyłania strumieniowego.