Posted by Jerry Stuckle on 04/13/06 22:53

d wrote:
> "Andy Jeffries" <news@andyjeffries.co.uk> wrote in message
> news:pan.2006.04.13.15.33.42.697799@andyjeffries.co.uk...
>
>>On Thu, 13 Apr 2006 01:42:45 -0700, fletch wrote:
>>
>>>It is much more efficient to let the webserver deliver images directly,
>>>and as I see it, there is no _good_ reason not to go that route.
>>
>>What about situations where there are multiple front-end web servers
>>connecting to multiple database servers.
>>
>>You don't really want to allow users to upload images (profiles, forums,
>>etc) in to a folder on one of the machines (whichever one of the farm they
>>happen to connect to for the upload process) and then have to sync between
>>every server to every other server every few minutes.
>>
>>Of course, shared storage (NFS etc) is another way of getting the same
>>goal, but multiple DBs may be more fault tolerant.
>
>
> Shared storage is the answer in that situation - storing images in a
> database has such a massive overhead, not to mention cumbersome file access.
> It might be easier from the coder's point-of-view, but that doesn't mean
> squat to a project :)
>
>
>>Cheers,
>>
>>
>>Andy
>>
>>--
>>Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
>>http://www.gphpedit.org | PHP editor for Gnome 2
>>http://www.andyjeffries.co.uk | Personal site and photos
>>
>
>
>

I disagree here. Storing images in the database does not have to be "massive
overhead". If they are in their own table (with just id and image, for
instance), there is no overhead when accessing other information. As for
accessing the image itself, when the table is indexed the database can go
straight to the data block containing the start of the image and read from
there. Overhead is not significantly different than what the OS has to do in
searching a directory to get to the file.

Sure, it's a little more overhead. But not that much. And sharing disks or
directories (I assume you mean that vs. memory - which only works on a single
server) can be problematic, also. For instance - storing images with the
equivalent of an autoincrement field. The server has to get a directory
listing, find the next unused number and write the file. No problem here - but
what if two servers want to do it at the same time? Whichever one goes second
will have to detect the file already exists on open, and get a new directory
listing. A database will handle these situations.

All in all, if you don't use a database you're just moving the required code to
the program instead of letting the database handle it.

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

[Back to original message]