I've recently discovered a reason to store even large images in the database. We have call recordings that get stored on disk and then imported into SQL Server. Don't ask me why but I decided to doa reconciliation between the call files on disk and SQL Server. It turned out that people had moved the files several times, left some behind, moved some to different directories (some of which were never backed up), had lost many files in the process, etc, etc, ad infinitum.

None of that happened with the calls stored in the database even after several moves of the database. The cool part is that the files are right there with the keys to look them up. The "bad" part is that backups have gotten huge and, of course, a restore would take hours. There's a solution for that, though. These calls are, by their very nature, "read only". We're partitioning the call recording table by month with each partition in its own read-only file group. We'll only keep the current month and the previous 3 months in the PRIMARY file group to make restores a no brainer and to allow for "piece-meal" restores of the other file groups (again, 1 per month). This means instead of a 5.5 hour restore in a DR situation, we can get "back in business" in less than a half hour and take our sweet time restoring the older months and in an online fashion. Much like an archive bit in a file system, it allows us to really only backup the data that has changed (new call recordings) or that is super important even if it hasn't changed (previous 3 months).

I used to be one that said "Hell no, not in my database" to large binary "files" but I'm really starting to see some of the advantages to storing such data in the database when you combine that with some of the tools for handling larger tables. The added bonus is that the front-enders love it, management loves it (no lost or difficult to find recordings), and it has become a whole lot easier to manage the calls because they're guaranteed to all be in the same place.

One final thing... we keep the informational data for each call in a separate table and have a "sister" table for the recordings. This is kind of the best of both worlds because we can very quickly search the information table (very narrow row sizes and easy to index) and the recordings are "pulled up" only when the correct information is found. Of course, the recording table has the row ID of the informational table in it to provide the link between the two.