Pracuję na dużym systemie oprogramowania, który wykonał zarówno mechanizmy przechowywania załączników, jak i innych treści. Pierwsza iteracja systemu przechowywała wszystkie dane w blokach BLOB w DB. Przekląłem to wtedy. Jako programista mogłem pisać skrypty poboczne, które natychmiast operowały na danych i zmieniały je, kiedy tylko chciałem.
Przeszedłem około 10 lat i nadal zarządzam tym samym oprogramowaniem, ale architektura się zmieniła i zostało napisane ze wskaźnikami do systemu plików. Przeklinam go teraz i żałuję, że nie ma go z powrotem w DB. Mam dodatkową korzyść z kilku lat i pracując nad tą aplikacją w znacznie większej ilości i wielu większych sytuacjach, czuję, że moja opinia jest teraz lepiej wykształcona. Promocja lub migracja systemu aplikacji wymaga rozbudowanego skryptowania i kopiowania milionów plików. Pewnego razu zmieniliśmy system operacyjny i wszystkie wskaźniki plików miały zły separator katalogów lub zmieniła się nazwa serwera w miejscu, w którym znajdował się plik, i musieliśmy napisać i zaplanować proste instrukcje aktualizacji SQL z DBA w weekend, aby to naprawić. Innym jest to, że system plików i rekordy bazy danych nie są zsynchronizowane, dlaczego jest niepewne, ale po tysiącach dni działania czasami systemy nietransakcyjne (system plików i baza danych nie współdzielą kontekstów transakcyjnych) po prostu tracą synchronizację. Czasami pliki w tajemniczy sposób znikają.
Kiedy to wszystko znajdowało się w DB, migracja lub promocja środowiska była kwestią zrzutu i importu DB. Zmiany w wierszach mogą być odpowiednio kontrolowane, wszystko zsynchronizowane, a logi mogą być w razie potrzeby odtwarzane do punktu w czasie. Jasne, że baza danych jest duża, ale jest rok 2011 i to po prostu nie jest wyzwaniem dla baz danych.
Co jest warte, mieliśmy podobne problemy z dużymi buforami danych podczas przesyłania strumieniowego niektórych danych, ale A) mogliśmy pompować dane w buforach bajtowych za pomocą Input|OutputStreams w JDBC i B) podczas korzystania z innych narzędzi, napisaliśmy procedurę składowaną który podzieliłby BLOB na tabelę tymczasową i iteracyjnie serwowałby porcje z tabeli tymczasowej. Działa świetnie.
Nie obchodzi mnie, jaki jest techniczny powód nie umieszczanie tych rzeczy w bazie danych, ale jest to o wiele łatwiejsze aby zarządzać w skonsolidowanej lokalizacji, mogłem w krótkim czasie podwoić i potroić sprzęt lub utworzyć sieć DB za czas zmarnowany przez konsultantów i klientów na zarządzanie różnymi plikami.
Aktualizacja:nie przejmuj się komentatorami, po prostu wyrażają swoją opinię w tej sprawie.
