object databases for symbolics

[attila@flash.bellcore.com (Leslie A. Walko)]

    >From:  pan@athena.Pangaro.dialnet.symbolics.com (Paul Pangaro)
    > 
    > We are evaluating how to proceed with a complex software application
    > running on the Symbolics, which needs to be able to create and maintain
    > large databases on the Symbolics, 

	...

    > We can deliver for some time on Ivory products, but later want to move
    > to other platforms. We want to stay object-based, of course, and don't
    > want to port to "C" or anything else anytime soon.
    > 
    > We are looking into a conversion to G-Base (from Graphael, whose

That is very clever on the part of ODI.  Offer something now, and sell
your own stuff later to the same client.

    > products are now distributed by Object Databases, Inc. in Cambridge)
    > now; we know of course about Statice but have not seen it since its
    > pre-release version.
    > 
    > Anyone have any experience with these issues? These products? Any
    > advice?
	...

There are only a few commercially released semantic or object oriented
DBMSs to choose from. These include: G-Base (Graphael), V-Base
(Onto-Logic) GemStone (Servio-Logic), SIM (Unisys).

Conceptually, GemStone is persistent Smalltalk.  It runs on Vaxen, SUNs
in a server-requester architecture like Statice.  It uses a programming
language called Opal which is their version of Smalltalk-80.  The
graphics are interesting and available in color.  They support a C
language call level interface.  Making the connection from GemStone to
Flavors may be possible, but the incompatibility of OS, languages, and
hardware would make this route quite a challenge.

SIM is a full featured commercially robust Semantic DBMS based on Daplex
(David Shipmann) and Semantic Data Model (Hammer and McLeod).  Since
Statice is also based on Daplex, the conceptual differences between
Statice and SIM are quite trivial.  However, the implementations differ
greatly.  SIM is blindingly fast; on the biggest A series multi-
processor mainframe, it can perform up to 1,000 transactions per TP1
benchmark.  It also has very sophisticated site operation capabilities.
It is truly an industrial strength DBMS where none of the others are
--Statice, GemStone, G-Base, etc.  Alas, SIM runs on a Unisys mainframe
under MCP.  The host language programming interface is your choice of
COBOL, Algol, Fortran.  Graphics are primitive to say the least, and the
hardware is *very* expensive. [I think they charge $250,000 for an 8
MWord memory card.]  On a more positive note, SIM will be available
under UNIX in 1991 and will probably have a C language interface.

[We have been running SIM since 1988.  So we have a fair bit of
experience with it.]

I don't know much about V-base, and you are already familiar with
G-Base.

There are so many university prototypes that it is hard to keep track of
them.  Postgres from UCB, Orion from MCC, Iris from H-P are some of the
better known ones. Postgres is really extended relational, so it would
not suit you well.  The others are truly object-oriented.  As a group,
they have novel features they are generally very buggy, and features
come and go every month.  

We have tested several of these prototypes.  One *almost beta* [I cannot
say which one] oo-dbms we tried 2 months ago was SO SLOW that we could
not even BEGIN to benchmark it.  At the rate it was inserting records,
it would have taken 3 years (yes, 3 years) to load our database before we
could begin the benchmark.  [This was on a Unix file server with 33MHz
Motorola 68030, 48MB of memory, with multiple SMD drives. No other
process was running while we attempted to load.  The vendor promised a
100X performance improvement *real soon*.] Another one we tried runs
so-so on a Symbolics 3675 and so slowly on SUNs that it makes a
hypertext collaborative writing tool we built quite un-usable.

There is vapor-ware:  depending on who you listen to, theirs is the
best.  Don't believe a word they say!  It doesn't matter who wrote it,
who the president is, or how many billions the parent corporation has.
My advice is to wait 6 months after a product is commercially released.
If the company is still in business after 6 months, the software might
be robust enough by than to run a few SIMPLE benchmarks.  Don't expect
miracles! AT LEAST TWO YEARS OR ONE MAJOR RELEASE IS REQUIRED BEFORE
THEY WILL BE COMMERCIALLY USABLE.  Even than, 90% of customer complaints
will be related or caused by oo-dbms problems.  

Now about Statice.  Statice is Flavors compatible.  It has been on the
market long enough by now, that I can regularly run benchmarks on it.
It does not crash, it does not take 3 years to lead my data, etc.  The
documentation is very good and quite informative about known
deficiencies.  [This is pretty important.  Most vendors keep very quiet
about their dirty laundry.  Your waste months on a problem only to find
out that the product of your choice does not support the feature you
need.]  So, Statice actually works.  I cannot say how fast yet --proper
benchmarks take months to run and even then they are only guidelines--
but my perception is that it compares to commercially available
relational dbms performance say 3 to 5 years ago.  In other words, with
careful design you can do real work now.  Performance should get better
as CPU, disk and especially as the software improves.

If you decide to deliver on Statice, you should know that
maintainability and performance tuning are fairly week in comparison
to commercial relational DBMS. There is very little control over the
physical schema and you have to do physical schema re-orgs off-line
[load-reload].  Even more embarrassing, some physical re-orgs destroy
your data.  I don't think your customers will stand for that.  [This
last problem is trivial to fix.  Building dynamic re-org facility would
be a lot harder.]

In two years there will be far more oo-dbms to choose from.  The way it
is right now is like 1981 was for relational dbms technology.

Leslie Walko
DataBase and Systems Research Group
Bellcore, scenic New Joyzee