Comments

Richard@Home, I have been using this method for some time now and I have had no problems. The tradeoff between this and a direcory scheme is one that I will accept. I have had no problems with the speed in a script similar to this (although I configured my SQL tables as best as I found possible).

The one thing i have to say about this is that is easier to secure. just throw down mysql_real_escape_string() and it is pretty hard for anyone to upload a malicious image (ie. PHP embedded GIFs) because the PHP is handling the headers and outputting the file before there is the chance to execute anything else.

If you are using plain old directory storage, your file sits on the webroot or wherever and can be directly downloaded via the browser. I tend to let PHP handle all my files anyways, and something like this could be integrated into an access control script, or a hotlink blocker, etc. very easily.

I have to say, so far MySQL images ftw. Great article Kevin; shoot me an email if you want to improve upon it a little, as I may have a few suggestions.

Sorry, still don't agree. It's still a bad idea. By all means store the meta data about an image (with a field for storing the filename) in a database because that's what the users are going to be searching for. Let's have a look at your benefits one by one:

Referential Integrity

This is the only benefit as far as I can see, and its a pretty tenuous one at that. It's pretty trivial to right some code that checks periodically if an image in the database has gone missing.

Ease of Backup

As opposed to what? The regular backup you perform of your website/application anyway?

Saving of Inodes

Dubious to say the least. I've created image directories with hundreds of thousands of images in with no problems. In fact, storing the images as files is better because if you need to increase the space for the images you just add a new hard drive and symbolically link the new directory.

Easy Categorisation

Which is just as easy as storing a link to the file along with its meta data.

Central point of operations

No, because now your image editors have to add another step to the process. Instead of just opening up an image in an image editor, making a change and saving it, they now have to upload it too. With all the problems of browser time-outs to complicate things even further. Also, you have to go to the additional step of pulling the (by definition, large) binary data out of the database, squirting it into an output file with the right headers and then sending the file to the browser. That's one more database query that could bring a busy website to its knees.