diglib: More on databases

[Robert Felsing <felsing@OREGON.UOREGON.EDU>]

        I suspect that some of us left the last diglib meeting feeling a bit
grim about the situation vis-a-vis databases.

        This is the route being traveled by e-Asia.  I make no claims that
this is the best route -- and it most certainly isn't the only route.

        The e-Asia database, which is far more encompassing than just the
materials that we convert and scan, has been frozen since September in order
to deal with content.  I am hoping very soon to return to database work once
I get a massive novel converted and two issues of an e-journal out.  This
plus the regular rigors of doing east asian bibliography.  (I know you feel
my pain ..... )

         Sloooowly I am transitioning the e-asia Filemaker database to an MS
SQL Server 7.0 database in conjunction with ColdFusion.  I am using
ColdFusion to build web pages for input/update/query of the database (which
will ultimately be four databases, each with a potload of tables).  As JQ
noted, Dreamweaver UltraDev is a disappointing tool for database
construction.  As an HTML editor, Dreamweaver is still tops in my book,
however.  What I am using to develop the database is ColdFusion Studio.
Most books on ColdFusion come with a CD that has a 30 day trial of
ColdFusion studio.  It's a very fine tool -- not surprising since it is
focused on the ColdFusion way of the universe and nothing else.  The Studio
is essentially Allaire's Homesite, a text editor for HTML, together with a
batch of ColdFusion and database development tools.  Homesite is itself a
superb tool for HTML.  

        As a big-database newbie and a non-computer person I find the
hardest part of the whole thing is the database design -- which has more to
do with having a sharp analytical mind than with computer skills.  I don't,
though, want to trivialize the rest of the operation -- there is a real big
learning curve.  And most of us probably would rather NOT know the different
flavors of inner and outer joins for SQL tables. 

        Web-connected Access or Filemaker databases do offer a possible
solution.  With these solutions, however, you have to worry about capacity
to take simultaneous users of the database.  Access is really not a
production database for the web and can only take a small number of
simultaneous users.  The standard version of the latest Filemaker has been
crippled by Apple (its maker) and is worse than useless.  On the other hand,
Server and Unlimited editions of Filemaker are probably significantly better
than Access.  Both Access (I think) and Filemaker can connect to and
communicate with SQL databases via ODBC.  Both database programs are
relatively easy to learn but the cost comes in performance and in basic
capability to do the things that you need to do.  The school of education
evidentally makes heavy use of Filemaker for web databases. 

        Maybe an example from Collection Development might suggest a way
out.  The database of International newspapers was built and is maintained
by friendly folks in Reference, Coll. Dev., and Cataloging. This is done
through the use of web forms.   Faye is adept at dealing with this database.
Probably most of what we in the library intend to do with database projects
is bibliographic.  I am willing to bet that much of what we want to do will
have basically the same database structure (and not terribly complex).  We
might be able to get by with one or two SQL database "templates" that could
be minimally altered to meet special needs and front-ended with web forms
(made pretty by your department's HTML guru).  It won't be Innopac and it
won't be enhancement friendly because of our limited resources, but it is a
possibility.  

       Bob Felsing