Posted by Michael Fesser on 12/13/06 14:46

..oO(Jerry Stuckle)

>Actually, quite a few reasons. Makes backups easier, ensures your
>database remains consistent, you don't need to keep track of thousands
>of images in one directory, no worries about name collisions, remote
>access...

None of them is a real problem.

>It won't take any longer to transfer the image through the MySQL
>connection if you're on the same server

It will _definitely_ take longer, see below.

>And table rows will be larger - but you'll still have
>to take up that space in the file system, anyway.

A typical RDBMS is not very effective in handling large binary data,
simply because it's not made for that purpose.

>I find storing images in the database can be very effective.

I don't. In some rather rare cases there might be reasons to do it, but
usually it will be a performance hit, especially when you want to build
an image gallery with a lot of images.

For every(!) single non-static image you have to call a PHP script,
which already slows things down:

<img src="/getImage.php?file=foo.jpg" alt="">

It gets even worse if every script call also has to open a connection to
the database and fetch the image from there. A hundred images on a page
means a hundred script calls and a hundred database connections. Compare
that to static images that are delivered instantly by the webserver.

Currently I'm in a situation where I will have to deliver large image
galleries entirely by scripts, including the images, for security
reasons (I use my own auth system, not HTTP authentication). I really
expect a dramatically impact on downloading time when the script is
finished. I don't like to do it, but in this case there's no other way.

Micha

[Back to original message]