Re: Browser Issue
- From: "d" <d@xxxxxxxxxxx>
- Date: Thu, 13 Apr 2006 19:34:25 GMT
"Jerry Stuckle" <jstucklex@xxxxxxxxxxxxx> wrote in message
news:pYmdnV2izOjfAqPZnZ2dnUVZ_uWdnZ2d@xxxxxxxxxxxxxx
d wrote:
"Andy Jeffries" <news@xxxxxxxxxxxxxxxxxx> wrote in message
news:pan.2006.04.13.15.33.42.697799@xxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxx
==================
.
- Follow-Ups:
- Re: Browser Issue
- From: Jerry Stuckle
- Re: Browser Issue
- References:
- Browser Issue
- From: Materialised
- Re: Browser Issue
- From: ColdShine
- Re: Browser Issue
- From: Materialised
- Re: Browser Issue
- From: fletch
- Re: Browser Issue
- From: Materialised
- Re: Browser Issue
- From: fletch
- Re: Browser Issue
- From: Andy Jeffries
- Re: Browser Issue
- From: d
- Re: Browser Issue
- From: Jerry Stuckle
- Browser Issue
- Prev by Date: Re: Passing database info into URL
- Next by Date: Re: US phone number validation
- Previous by thread: Re: Browser Issue
- Next by thread: Re: Browser Issue
- Index(es):
Relevant Pages
|