Posted by Jerry Stuckle on 12/13/06 19:06

Michael Fesser wrote:
> .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.
>

Sure they are. What happens if you accidentally delete an image from a
directory? What if you have the images on another server and want to
restrict access? NFS may not be available. How about keeping thousands
of images in a single directory? Even Linux slows down when the number
of images gets big enough. And how about keeping track of names so you
don't get duplicates?

They are all real problems.

>
>>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.
>

It doesn't have to.

>
>>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.
>

Have you actually checked? I think you'll find MySQL can be quite
effective in handling them. And RDBMS's are made to handle data - even
large blobs, which is all the image is to the database.

>
>>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.
>

That's our choice. But I find performance to be quite good, and
improves with larger numbers of images.

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

So? If you want to protect your images, you'll have to call your PHP
script anyway. No big deal.

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

So?

> 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.
>

So? Every script also has to open a file and read it in. A hundred
images on a page means a hundred script calls and a hundred file system
accesses. Worse if the data is on another server (and not available via
NFS).

> 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

That could be. But I don't think you'll find a database to make things
any worse.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]