Re: images in databases
Re: images in databases
- Subject: Re: images in databases
- From: email@hidden
- Date: Fri, 25 Feb 2005 13:22:48 -0800
On Feb 25, 2005, at 11:46 AM, Pierre Frisch wrote:
Bill I disagree with you on that one. The only reason for not storing
the images in the db is because WO does not support it very well.
There are a number of way you can improve WO to make it behave and I
have done it successfully, if only Apple could listen and fix it for
everyone we would not have that discussion every few months. On the
other side having the images outside of the database essentially
destroy the initial reason for having a database. The drawback of
having operational information on two different repositories (db and
file system) are not negligible in particular backup, security and
synchronization issues.
That has not been my experience across many years of building WO and
non-WO based solutions. Any time a system has had to scale, storing
BLOBs in the database has proven to be a major bottleneck. Unless the
database is directly responding to inbound HTTP requests-- a feature
that Oracle, likely others, added a while ago-- pushing the images to
beyond the web server adds a huge amount of overhead while vastly
limiting your deployment options.
Also, serving the images out of the filesystem often leads to shorter
URLs and a smaller amount of content being served per client -- in one
case, we were able to drop our server side bandwidth by 60% simply by
ripping the images out of the DB and shoving 'em onto the webserver
into the /i/ directory. Of course, now that bandwidth is both cheap
and plentiful, efficiency hacks of this nature are no longer nearly as
important or valuable.
And, as PA said, what is the point of storing opaque binary data in a
relational store anyway? The data can't be effectively indexed or
queried. End result; shoving it into and pulling it out of the
database is pure overhead with the only advantage-- that I can see--
being that WO/EO make it terribly convenient to do. Storing paths or
relative URLs in the database isn't much harder and significantly
improves the flexibility with which one can address scalability and
other deployment issues. Apache is an incredibly configurable web
server. It can often perform very complex administrative style tasks
such as authentication, access management, remapping, caching, etc..
with only a few lines in a config file that would require many lines of
code, regardless of server technology.
Obviously, if scalability is not an issue, then -- by all means --
shove those images in the database if that is the most convenient thing
to do! A shipping, somewhat suboptimal, product is always better than
the perfect product that never ships.
Beyond the obvious performance/scalability reasons previously
discussed, storing the images outside of the database has the other
advantage of not requiring the data to be finagled into a renderable
form. The images can be viewed directly in the filesystem. I often
worked on projects where the graphic/arts production team would work in
a tree full o' images and we would simply rsync their stuff into
production (or testing), as needed. Or it would be managed through
CVS (blech) as a separate tree of stuff. This avoided having to
create and maintain yet-another-administrative WO app to load/manage
images in the database.
Certainly, there is no one right answer that covers all situations.
b.bum
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden