EXACTLY my point. There have been several comments to the list regarding how
easy several database products (Access, Filemaker, etc.) are to use. True.
They all can be customized and all will help you organize data. That is how
databases are _supposed_ to function. Heck, x-base and foxpro work too. For
that matter you could use SPSS. You still have to program them. The user
still has to design screens, write code, produce links, and DOCUMENT what
was done.
I consulted for a large natural history museum that is using a database, not
a collections management package, to organize very basic descriptive
information about its collections. The database package itself is fine, the
implementation stinks. It replicated the catalogue cards and was about as
useful as a bicycle is to a fish. There was no documentation, no user
manuals (specific to the site) no consistency of data entry, none of the
tools (approved lexixcon lists for example) that would have ensured the use
of appropriate terminology.
In addition, while a collections management system would provide a means for
managing loans, scheduling conservation treatment, assigning
cataloguing tasks to appropriate staff, this database didn't. Sigh.
Here's my standard harping: Evaluate your needs, compare packages, and if
you need a Collections Management System--buy one.
Diane Gutenkauf
On Fri, 8 Oct 1999 15:33:27 -0700, Andrew Morrow <[log in to unmask]>
wrote:
>I have some off-the-cuff thoughts that should be considered in regards to
databases. Technical support is an important factor that is often ignored
until it is too late. I have worked at two government agencies that opted to
use a customized database based on MS-Access. One was designed
>in-house and the other by a vendor. Both lacked proper support and
documentation. The worst of the two nightmares was an in-house database
where an amateur designer left the agency after producing a poorly designed
database. When a problem arose with the system, there was no person to turn
to
>in the agency that could rectify the situation. Nobody knew how the
database operated or the meaning of the various codes in the database
structure. I was hired as an outside contractor to salvage any data and
migrate it to another system that was being designed by another contractor
at
>enormous expense. If you choose to design a database for your organization,
be sure to produce support documentation. Include not only information for
the end user that will use the application, but also information regarding
the program structure and codes so that others have a clear
>understanding of how the application operates. Better yet, be sure more
than one person fully understands how the application works and how to
trouble-shoot if problems arise.
>Institutions may also consider a customize database produced by an outside
contractor or purchasing an off-the-shelf system. When selecting a product
or contractor, be sure to consider the reputation of the company. In the
ever-changing computer world, there are many fly-by-night companies. If
>a company disappears, you may be left with a product that nobody will
service, or can only be serviced by another company at great expense. Such a
situation happened at another agency where I worked. Some vendors do offer
customization for their off-the-shelf product, again at a higher expense
>both in production and in service. This discussion group has already
mentioned several reputable vendors. Has anyone produced a comparative
survey of these products?
>
>
=========================================================
Important Subscriber Information:
The Museum-L FAQ file is located at http://www.finalchapter.com/museum-l-faq/ museum-l.html. You may obtain detailed information about the listserv commands by sending a one line e-mail message to [log in to unmask] The body of the message should read "help" (without the quotes).
If you decide to leave Museum-L, please send a one line e-mail message to
[log in to unmask] The body of the message should read "Signoff
Museum-L" (without the quotes).
|