Pracuji na velkém softwarovém systému, který udělal oba mechanismy pro ukládání příloh a dalšího obsahu. První iterace systému uložila všechna data do BLOBů v DB. Tenkrát jsem to proklínal. Jako programátor jsem mohl psát postranní skripty, abych mohl okamžitě pracovat s daty a měnit je, kdykoli jsem chtěl.
Postoupil jsem o 10 let a stále spravuji stejný software, ale architektura se změnila a byl napsán s ukazateli souborového systému. Teď to proklínám a přeji si, aby to bylo zpátky v DB. Mám další výhodu několika let a tím, že jsem pracoval s touto aplikací v mnohem větší kapacitě v mnoha dalších a mnoha větších situacích, cítím, že můj názor je nyní vzdělanější. Propagace nebo systémová migrace aplikace vyžaduje rozsáhlé skriptování a kopírování milionů souborů. Při jedné příležitosti jsme změnili operační systém a všechny ukazatele souborů měly špatný oddělovač adresářů nebo se změnil název serveru tam, kde byl soubor, a museli jsme na víkend napsat a naplánovat jednoduché příkazy aktualizace SQL s DBA, abychom to opravili. Další je, že se souborový systém a záznamy DB nesynchronizují, proč není jisté, ale po tisících dnech provozu se někdy netransakční systémy (systém souborů a DB nesdílejí transakční kontexty) jednoduše nesynchronizují. Někdy soubory záhadně zmizí.
Když to všechno bylo v DB, migrace nebo propagace prostředí byly záležitostí výpisu a importu DB. Změny řádků by mohly být řádně auditovány, vše synchronizované a protokoly lze v případě potřeby přehrát k určitému bodu v čase. Databáze se jistě zvětší, ale je rok 2011 a tohle prostě není pro databáze výzva.
Co stojí za to, měli jsme nějaké podobné problémy s velkými datovými vyrovnávací paměti při streamování některých dat, ale A) mohli jsme pumpovat data do bajtových vyrovnávacích pamětí pomocí Input|OutputStreams v JDBC a B) při použití jiných nástrojů jsme napsali uloženou proceduru to by rozdělilo BLOB do dočasné tabulky a iterativně obsloužilo bloky z dočasné tabulky. Funguje skvěle.
Je mi jedno, jaký je technický důvod ne vložení těchto věcí do DB, ale je to tak mnohem jednodušší pro správu na konsolidovaném místě bych mohl zdvojnásobit a ztrojnásobit hardware nebo mřížku DB za čas, který ztrácejí konzultanti a zákazníci, a to jen během krátkého časového období správou různorodých souborů.
Aktualizace:jděte klidně na komentující, oni jen vyjadřují svůj názor na věc.