BLOBs – The AIG of Data Integrity

OK – so there is no one-size-fits-all way to define the use of BLOBs in your database.  But this crazy bandwagon of putting file storage into BLOBs really has me baffled.  I think it is…well…down right stupid.  Why the metaphor with AIG – because people are treating BLOBs like they represent an additional layer of “insurance” against catastrophic failure… they pretend that if they use BLOBs, their solution must fall into the “Too big to fail” category and will qualify for a stimulus package. Hog Dasz.  That’s a technical term created from washing hogs using ice cream.  Using BLOBs, to me, is like storing your household pets in a vacuum cleaner.

When companies like Microsoft (e.g. SharePoint) and Metastorm embrace BLOBs as they have – they send out waves of marketing that indirectly imply that, since their solutions are the bestest everer, BLOBs must be the BEST way to store files; However, when comparing storage of files on a file system (or file share), vs. storing them in a database as Binary Large Objects (BLOBs),  my vote is against BLOBs.  IMHO, filling a database with BLOBs:

• Causes unnecessary bloat on the database, making it harder to manage
• Causes unnecessary processing, as the files must be marshaled into and out of the database
• Introduces risk because once the files are in the database, the only way to get them back out is through the vendor application
  • This marries the organization to the vendor
  • If the database server goes down, so do the files
    • This same argument could be made for file servers – if a file server goes down then the files cannot be accessed.  Read on for my counter to that opinion.
• Introduces undue complexity
  • If a file server goes down, it can readily be restored from backups without requiring the vendor product be installed and configured, and without the installation and configuration of SQL Server or another database.
  • File systems have the ability to work with RAID and SAN architectures directly for redundancy – adding them to BLOBs buys nothing but the above hassles
  • Providing additional file storage is comparatively easy
  • In a virtualized environment, the files are a a couple layers of abstraction farther from the hardware – that is NOT the best thing; however, it is part of the price of introducing virtualization and cloudness to the world.  But… adding even more layers by marshaling files through a vendor application and then into a BLOB that is accessed through a database just makes your virtualized environment layered…like Ralphy’s winter garb in “A Christmas Story”.  It’s too much I say! Lay off the BLOB-crack!

Maybe someone will have a rationale in favor of BLOBs, maybe there is a time when even I will leverage a BLOB intentionally.  But I am hard-pressed – my current perception says, if it is a BLOB, treat it like a file and store the pointer in the database.  Yes, the pointers must be maintained.  Yes, the permissions on the file system should stop people from willy-nilly moving files around.  Yes, perhaps there is some loose coupling with the software that manages those files, but in a pinch…you HAVE your files…and NOBODY CAN TAKE THAT AWAY FROM YOU! (sniffle, hug)

Stay Beautiful.  Stay BLOB Free.