Re: Advice on dynamic graphics with WO
Re: Advice on dynamic graphics with WO
- Subject: Re: Advice on dynamic graphics with WO
- From: Arturo Pérez <email@hidden>
- Date: Fri, 2 Jan 2004 11:48:45 -0500
On Jan 2, 2004, at 8:46 AM, Tom Pelaia wrote:
Just to continue the discussion.
We grab images from the database in our WebObjects application
(electronic logbook). It is a very heavily accessed site and allows
users to make entries that have text, images and other attachments. We
have found additional "pros" for loading images from a database.
Additional database pros:
1) The logbook isn't the only application that uses our database. We
just use a subset of the database. Other applications write to the
database and make entries into our logbook and use data from our
logbook. Storing complete logbook entries (images, text, attachments)
in the database means other applications have easy access to logbook
entries. Hence we are integrated well.
That just has to do with software design. This isn't a claim that's
made easier by using a database. (Note, I'm not saying you're wrong).
If you carefully design the system then whether there's a database there
or not isn't really apparent. For example, say I made this whole thing
a WebService backed by the file system. Isn't that just as easy?
2) The database is the one official source of all data.
What if I say "the filesystem is the one official source of all data?"
How is that a pro/con?
3) Backups are consistent and easy. When the database is backed up,
all
logbook data is backed up and the backups are self consistent.
I don't understand this point.
4) It is easier to transfer data from one machine to another since you
only have one thing to transfer.
You mean one database record? And what if I store the data in an XML
file with the image embedded? That's still just one thing.
5) Since the images are provided by users, the database provides a way
to avoid file names collisions. If you use a file system you need to
save filenames carefully to avoid duplication.
Now there's a win. That's why I said you'd probably still need some
sort
of database for management. Unless WebDAV addresses this issue?
6) The first logbook we developed several years ago (without WO) stored
data including images in the filesystem. That turned out to be very
inflexible. If you want to reorganize the folder layout, lots of links
will break. This is simply a non-issue for database storage.
Yep. But if you build a system with "dynamic" URLs the images can still
be in the filesystem. But some would consider that an extra layer.
7) Databases are simply much more flexible. Filesystem storage is very
rigid. You can store your files for the present application, but needs
tend to change in time and database storage is much more flexible in
supporting future needs that you might not be considering today.
Now this is just plain wrong. Filesystems are enormously flexible.
That's
been proven over at least 40 years. RDBMS still trail by 20 :-) But
if you
believe that you can't move things around (or shouldn't) then you have
a point.
At a minimum you'd need to implement some sort of catalog for the
images on
disk. How you choose to do that is up to you. But most people would
use an
RDBMS these days. Apache can even do some of this for you if you're
comfortable
with its mechanisms.
Whether you choose database storage or filesystem storage really
depends
on your application. For our application, the electronic logbook is
becoming more integrated with other systems and the database has turned
out to be critical in that integration.
Exactly. Fun discussion, BTW. For me, personally, I tend to view
databases
as expensive complicated pieces of machinery best used when such is
needed.
Subject:
Re: Advice on dynamic graphics with WO
From:
Arturo Pirez <email@hidden>
Date:
Thu, 1 Jan 2004 10:47:58 -0500
To:
Geoff Hopson <email@hidden>
My opinion and experience FWIW, having done it both ways. I keep
having this discussion so
I'd thought I'd put it all down in one place.
Database pros:
1. It's really easy.
2. It works well.
3. It's consistent with everything else; i.e. all data comes from the
database.
Database cons:
1. There are some tuning issues around BLOBs if you're using those (or
equivalent).
2. I don't understand people saying "It solves single point of
failure." Didn't you just move
the single point of failure from a file system to the database? Sure,
databases offer replication
but you can achieve the same with a clusterable file system like
Transarc or the Andrew File System (AFS).
3. It "makes no sense." It's just storing a bunch of non-relational
data in a relational database. It feels
unclean :-)
4. If you need to manipulate the data it's much much harder. For
example, if it's text and you want to
fix a typo it's problematic. If it's an image updating EXIF headers
would be a chore. It's much easier
to run a perl script over a directory of files.
Filesystem pros:
1. It scales better.
2. It's easier to manipulate the images if that's necessary.
Particularly offline from serving them.
3. It's cheaper. (Disks are cheaper costwise than databases esp. if
you need a DBA).
Filesystem cons:
1. It's a little harder to manage. And you might still need a
database to keep track of the images.
2. It's harder to build a content management system that can upload
images. WebDAV might address this issue.
Well, my 2 farthings.
----
WO in philadelphia - wanna cheesesteak with that?
Please visit webobjects.meetup.com.
--
Tom Pelaia
SNS Project, 701 Scarboro Road, MS-6473, Oak Ridge, TN 37830
phone: (865)574-6421, fax: (865)574-6617
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
----
WO in philadelphia - wanna cheesesteak with that?
Please visit webobjects.meetup.com.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.