Jeg arbejder på et stort softwaresystem, der har lavet både mekanismer til lagring af vedhæftede filer og andet indhold. Den første iteration af systemet lagrede alle data i BLOB'er i DB. Jeg forbandede det dengang. Som programmør kunne jeg skrive sidescripts for straks at betjene dataene og ændre dem, når jeg ville.
Advance omkring 10 år, og jeg administrerer stadig den samme software, men arkitekturen har ændret sig, og den blev skrevet med filsystempointere. Jeg forbander det nu og ville ønske det var tilbage i DB. Jeg har den ekstra fordel i flere år, og efter at have arbejdet med denne applikation i meget større kapacitet i mange flere og mange større situationer, føler jeg, at min mening nu er bedre uddannet. Promovering eller systemmigrering af applikationen kræver omfattende scripting og kopiering af millioner af filer. Ved en lejlighed ændrede vi OS, og alle filpegerne havde den forkerte mappeseparator, eller servernavnet ændrede sig, hvor filen var, og vi var nødt til at skrive og planlægge simple SQL-opdateringssætninger med DBA i weekenden for at rette dem. En anden er, at filsystemet og DB-posterne bliver ude af synkronisering, hvorfor er usikkert, men efter tusindvis af dages drift bliver ikke-transaktionelle systemer (filsystem og DB ikke deler transaktionskontekster) simpelthen ude af synkronisering. Nogle gange forsvinder filer på mystisk vis.
Når alt dette var i DB, var migration eller miljøfremme et spørgsmål om dump og import af DB. Rækkeændringer kunne revideres korrekt, alt synkroniseret og logfiler kan afspilles til tidspunktet, hvis det er nødvendigt. Selvfølgelig bliver DB'en stor, men det er 2011, og det her er simpelthen ikke en udfordring for databaser.
For hvad det er værd, havde vi nogle lignende problemer med store databuffere, når vi streamede nogle data, men A) vi kunne pumpe dataene i byte-buffere med Input|OutputStreams i JDBC og B), når vi brugte andre værktøjer, skrev vi en lagret procedure der ville dele BLOB'en i et temp-bord og iterativt servere bidderne fra temp-bordet. Fungerer godt.
Jeg er ligeglad med, hvad den tekniske grund til ikke at lægge disse ting i DB, men det er så meget nemmere for at administrere på en konsolideret lokation kunne jeg fordoble og tredoble hardwaren eller opbygge DB'en for den tid, der spildes af konsulenter og kunder på kort tid med at administrere de forskellige filer.
Opdatering:tag det roligt med kommentatorerne, de giver bare deres mening om sagen.