#Databases on CD-ROM
8 messages in this thread
Gary,
I'm on my second CD ROM that is basically .DBF files. My client has a lot of
archival data (10 years x 40 MB per year). He wants to be able to run simple
statistics against those data and produce a set of standard reports (lots of
graphics).
The first time through I took the same approach I would on a disk-based
database. I formatted the data in what I thought would be the most useful form
and added indexes on the fields I thought most useful.
This time my main goal is redundancy. No matter what database engine you are
using CD ROMs are S L O W when you have to go read the disk. Disk intensive
functions include accessing multiple indexes, linking and joining tables,
running the same query often (e.g. generating summary tables or lists of names,
etc.). The big advantage of CD is that you can provide duplicate data in many
different formats and cut down number of disk accesses.
What proprietary markup language are you thinking of? I've had perfectly good
luck putting my files on 9-track tape and shipping them off to a One-Off shop
for production. My limited experience to-date is that intelligent planning in
setting up your application and DBF files are the most important factors in
getting a good system built.
One caveat. If you think you might want to use MS Access on your database you
should know that a bug in the current version (1) of Access prevents you from
attaching DBF files on read-only media (CDs and networks) if you have any
indexed fields. MS claims this will be fixed in the next release.
Jeffrey William Gillette
Jeffrey:
Congrats on some obviously frutiful and insightful use of CDROM in real-life.
The issues you describe, and your caveats regarding them, are very helpful.
>>Disk intensive functions include accessing multiple indexes, linking and
joining tables, running the same query often (e.g. generating summary tables or
lists of names, etc.).<<
Your point here is particularly well-taken. CDROM is often slow becuase the
developer is trying to use it like a traditional mag disk, instead of the
different medium and device it truly is. Relational works well on hard disk,
at least partially, because disk acess in that environment is "cheap and easy."
I wonder if you have developed any techniques for maintaining relational data
effectively on CDROM. How does your "multiple copy" approach work?
Thanks.
Rich Bowers
Rich,
My limited experience with databases so far suggests that 200 – 400 MB is a
good size for a corporate database on CDROM. If your tables support lots of
relations you go towards the lower number. If your tables are pretty much
self-sufficient you can go towards the higher number.
How to keep multiple copies of your data depends on what your client needs. The
client I am working with now regularly uses two consultants – I write apps in
Access, and the other consultant is a "Clipper-head". For the first CD I
decided to include all the tables in a lowest-common-denominator format (dBase
III+ with .NDX indexes). As a result, his apps are poor performers and I hit a
wall because Access does not support (contrary to all advertisements) attaching
a dBase table and index on a CDROM. This time all the data is going onto the
CD in *both* Access and Clipper formats.
One trick I am learning is to make better use of temporary and scratch tables
on the fixed disk. One of my apps is a '90 Census report generator. The client
wants to build a list of geographic areas (cities, counties, tracts, etc.) and
then print reports from the data. I've put all the selection data into one set
of tables (States, Counties, MCDs, Census Places, etc.) so that the app doesn't
get bogged down reading data fields until a region has been selected. Then,
before the reports get generated, I pull all the data for selected regions into
a temporary database on the fixed disk. The reports this client wants tend to
make heavy use of relations and analysis (lots of number crunching), and seem
to overwhelm the simple caching algorithms built into Access (lots of disk
reads).
There are two downsides to this approach: 1) CDROM looses a bit of its cost
effectiveness when you put a 300MB database on it instead of a 600MB database.
2) Keeping multiple versions of a table synchronized adds cost to
[OzCIS: Continued in next msg]
[OzCIS: Continued from previous msg]
the production. The client has to see that this is in his/her long-term best
interests.
Jeffrey William Gillette
Jeffrey:
Thanks for the great insights!
Best – Rich
Jeffrey,
You could mention _which_ One-Off shop <BG>
Kathy <<– The One-Off CD Shop MidSouth, Inc.
Kathy,
>> You could mention _which_ One-Off shop
Oh! You mean there's more than one? <g> Kathy has done one CD for us which
was exactly what we needed for a reasonable price. She is doing a second CD
even as I write this response. I am sure that it will be an equally big hit
with the clients.
Jeffrey William Gillette
Thanks for the << only slightly solicited >> endorsement, Jeffrey. 😉
Kathy <<– in crassly commercial mode
The One-Off CD Shop MidSouth, Inc.