|
|
Posted by Jerry Stuckle on 04/14/06 01:05
d wrote:
> "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
>>==================
>
>
>
Yep, I'm moving the work to a different database - the RDB, 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
==================
Navigation:
[Reply to this message]
|