Ik werk aan een groot softwaresysteem dat beide mechanismen heeft gebruikt voor het opslaan van bijlagen en andere inhoud. De eerste iteratie van het systeem sloeg alle gegevens op in BLOB's in de DB. Ik heb het destijds vervloekt. Als programmeur kon ik side-scripts schrijven om onmiddellijk met de gegevens te werken en deze te wijzigen wanneer ik maar wilde.
Ga ongeveer 10 jaar vooruit en ik beheer nog steeds dezelfde software, maar de architectuur is veranderd en het is geschreven met bestandssysteemaanwijzers. Ik vervloek het nu en wou dat het terug in de DB was. Ik heb het extra voordeel van meerdere jaren en nadat ik deze applicatie in veel meer en veel grotere situaties in veel meer en veel grotere situaties heb gewerkt, heb ik het gevoel dat mijn mening nu beter is opgeleid. Promotie of systeemmigratie van de applicatie vereist uitgebreide scripting en het kopiëren van miljoenen bestanden. Op een keer hebben we het besturingssysteem gewijzigd en hadden alle bestandsaanwijzers het verkeerde mapscheidingsteken, of de servernaam veranderde waar het bestand zich bevond en we moesten in het weekend eenvoudige SQL-update-instructies schrijven en plannen met de DBA om te repareren. Een andere is dat het bestandssysteem en de DB-records niet synchroon lopen, waarom is onzeker, maar na duizenden dagen gebruik raken soms niet-transactionele systemen (bestandssysteem en DB delen geen transactiecontexten) gewoon niet meer gesynchroniseerd. Soms raken bestanden op mysterieuze wijze kwijt.
Toen dit allemaal in de DB stond, was migratie of milieupromotie een kwestie van dumpen en importeren van de DB. Rijwijzigingen kunnen goed worden gecontroleerd, alles is gesynchroniseerd en logs kunnen indien nodig worden afgespeeld tot op een bepaald tijdstip. Natuurlijk wordt de database groot, maar het is 2011 en dit is gewoon geen uitdaging voor databases.
Voor wat het waard is, we hadden vergelijkbare problemen met grote gegevensbuffers bij het streamen van sommige gegevens, maar A) we konden de gegevens in bytebuffers pompen met de Input|OutputStreams in JDBC en B) bij gebruik van andere tools, schreven we een opgeslagen procedure dat zou de BLOB in een tijdelijke tabel opdelen en iteratief de brokken uit de tijdelijke tafel serveren. Werkt geweldig.
Het kan me niet schelen wat de technische reden is voor niet zet dit spul in de DB, maar het is zo veel makkelijker om op een geconsolideerde locatie te beheren, zou ik de hardware kunnen verdubbelen en verdrievoudigen of de DB kunnen roosteren voor de tijd die wordt verspild door consultants en klanten, in een korte tijdsperiode met het beheren van de ongelijksoortige bestanden.
Update:doe rustig aan met de commentatoren, ze geven alleen hun mening over de kwestie.