Re: Advice on dynamic graphics with WO
Re: Advice on dynamic graphics with WO
- Subject: Re: Advice on dynamic graphics with WO
- From: Jonathan Rochkind <email@hidden>
- Date: Sat, 3 Jan 2004 16:55:01 -0600
I am curious to know what mechanism you use to actually return the
images (stored in the db) to the browser. The ordinary way to do
this in WO would be with WOImage with a 'data' binding, but there are
a variety of problems with this involving memory management. If you
haven't encountered them even if your heavily accessed app, more
power to you. But I'm curious exactly how you are deliving the
images, and if you did anything special for memory management
purposes.
--Jonathan
At 8:46 AM -0500 1/2/04, Tom Pelaia wrote:
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.
2) The database is the one official source of all data
3) Backups are consistent and easy. When the database is backed up, all
logbook data is backed up and the backups are self consistent.
4) It is easier to transfer data from one machine to another since you
only have one thing to transfer.
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.
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.
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.
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.
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.
_______________________________________________
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.