MUSEUM-L Archives

Museum discussion list

MUSEUM-L@HOME.EASE.LSOFT.COM

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Robert A. Baron" <[log in to unmask]>
Reply To:
Museum discussion list <[log in to unmask]>
Date:
Wed, 5 Feb 1997 12:01:26 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (62 lines)
At 09:26 AM 2/5/97 -0600, Orycteropus afer <[log in to unmask]> wrote:

>You are right in wanting a relational system and the more open and more
>mainstream, the better.  Many of the systems on the market (including some
>of the ones mentioned in responses to your initial query) do not use open
>relational systems but rather proprietary database management systems and
>are based on off-brand commercial products or products that do not
>incorporate standard relational models.  The more mainstream the database
>management system, the more likely you will be able to find people who know
>how to use it or program in it and the more books available at the
>bookstore, help on the Internet, help from other museum users, etc.

While the above is correct in relating the advantages of standard
relational systems, it does not explain why Argus and some of the other
systems (Vernon's Collection, among them) use products based on the PICK
operating system, namely Revelation Technologies OpenInsight and Advanced
Revelation (AREV).

There is a reason for this choice that says much about the nature of museum
data and humanistic data in general.  Standard relational systems use an
architecture that requires that all normal fields be predefined in length
and fields that hold only a single value.  PICK and its derivatives use
open-ended variable length fields and permit multiple values to reside in
the same field.  In addition, this operating system permits fields to be
linked together in sets.  For most purposes such a structure provides a
very simple way of programming repeating relational data.  To replicate
such structure in standard relational systems requires very complex
structures and much burdensome programming.

Whenever the needs of an object management program begin to exceed the
normal object inventory and object loan format in common use, that is,
whenever it is necessary to include multiple lengthy references, and sets
of repeating and variable data must inhabit the most basic files in the
system, then the architecture used by Argus and Collection will appear very
attractive indeed.  Very easily a single table in AREV or OpenInsight can
expand to fifty in a relational system.

But the problem cited above by the quoted author is significant.  The world
is conforming (for better or worse -- probably for the worse) to the
standards of Oracle and its cousins.  It is becoming ever more difficult
for such PICK based systems to gain a foothold.  Indeed, Questor Systems,
the maker of Argus, recently announced that they are rebuilding Argus on
Oracle, and (presumably) abandoning OpenInsight.

So the question is the following:  What is going to lead your
decision-making process.  Will the popularity of the tools offered by the
database industry cause you to sacrifice your data to practicality? Or will
you consider your data supreme and allow the data to determine the
application -- old-time advice, surely, but wise, nonetheless.

After (or if) one learns that FileMakerPro and similar systems can't be
built to match one's needs, what choice is going to be made then?  The
answer involves the standard top-down, bottom-up dilemma.  What rules?  The
priorities of enterprise or the demands of the data?

===========================
Robert A. Baron
Museum Computer Consultant
P.O. Box 93
Larchmont, NY 10538 (USA)
mailto:[log in to unmask]

ATOM RSS1 RSS2