[LUNI] database question
maney at pobox.com
Wed Aug 7 11:16:02 CDT 2002
On Wed, Aug 07, 2002 at 09:54:13AM -0700, Richard Reina wrote:
> What I am going to do with them: Store and occasionally fax a copy or
> print a copy -- probabably once every 30 records. The documents are
> ussually 1 to 5 letter sized pages -- I don't know how big they'll be as
> imaged files.
Big. Amazingly big, if you haven't ever tried this before. Not big enough
to make this impractical, but big.
> There will be 1 document for each record in the database. The database
> grows currently at a rate of about 200-300 records per month, however,
> this could increase 5 fold in the next 2 to 3 years.
One question I forgot to ask is if the paper copies get shredded or filed
I guess you could cram the image data into the database, but I would wonder
if it's worth the trouble. Especially if you're keeping the paper on file:
then you'll need to carry a document ID around, and it would be pretty easy
to use that to figure out a file/path name for the image file.
Another advantage of using separate file storage is that, unless you're
planning to build an integrated tool for all of this, it will almost
certainly be simpler to deal with files rather than database records at both
the scanning and viewing/faxing ends of things - and the latter is the
reason for doing all of this, no?
Now, there are a few drawbacks with separate files. If you don't wrap the
process in a script, getting the scanned images into the right place is a
potential source of errors. This is part of the whole issue of keeping the
database and this external pile of data in sync. Even this could be an
advantage, though, if you ever wanted to put a part - the last year's
images, say - onto a CD for someone who needs to access the data away from
the central server. All the indexes and summaries, if you do them, would be
inthe database, but not all the document images. Maybe this doesn't apply
to your application, but what about long-term archiving? Will all the
images be kept online forever?
You can work around all these things more or less with either approach.
Separate files will require less up-front construction, and is easier to
adapt in some ways to the variant uses that may well arise; the cost of that
flexibility is that more care is probably needed to keep things
synchronized. Of course, you can start out with the simpler approach and
migrate the image files into the database later on if the benefits of that
are important enough. So I'd be very much inclined to start out with that
simpler approach, if only to get a working system in place sooner. That way
you can start learning from your "mistakes" sooner - and while they're
relatively small and easy to fix.
We had a lot of booming cyberanarchy in the USA for 20 years, and
now we are looking at several years of stagnant feudal nothingness.
I would guess about maybe one Presidential administration worth of
nothing. -- Bruce Sterling
More information about the luni