:)

I will agree, though, that in *most* cases storing images in the database is not the best solution overall for performance. But performance isn’t always the only factor, either. Sometimes it’s more important to have the database consistent, and have BLOBs be easily auditable in the same manner as other data.

I’ve always been a fan of looking at the entire picture when figuring out what to do. And just because something can do it doesn’t mean you should. I mean a hammer *can* open a peanut, doesn’t mean you should. A similar analogy I once read about storing blob data in a RDBMS: You can store the entire cow in a fridge, but wouldn’t it make sense to store it as steaks? Not that I am saying not to use blobs, just as with anything, use them wisely ;)

So I think the points you raise are good. There is no hard and fast rule. I would argue that in most cases storing large binary data that you need to access frequently might not be what you want to do on a high trafficked web site. However, if you can cache those files to disk to serve them, then where you store them might not be as big of a deal.

As you say it is all about finding the sweet spot in the system, in fact in *YOUR* system :) I was witness to a SQL Server implementation gone horribly wrong where thousands of binary attachments were stored into a database. I am not a SQL Server DBA so I can’t speak to the ins and outs of why it happened… however the result was that for 400 people (so not huge by any means) the DB started crawling and the backups of the DB became unmanageable. In the end I believe the system was changed to not store images and the whole thing improved dramatically.

With things like memcached these days and the potential to move images off to some high performance file system or even creating a CDN like system with a DB In the background I think there are lots of options.

I would even add how your server communicates with the DB in a particular network might even have an affect on which method you decide.

So many options.