Posted by d on 04/13/06 22:34

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:pYmdnV2izOjfAqPZnZ2dnUVZ_uWdnZ2d@comcast.com...
>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.

I'd put it that you're moving the work to a different database - the
filesystem, which is built for exactly this kind of thing :)

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

[Back to original message]