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, without worrying about "saving out" to
    > maintain a permanent copy of things. The current application is heavily
    > Flavor based, but with our home-brew tools is slow to "save out" and
    > will probably chock on retrieval as the knowldgebase gets bigger.
    > 
    > Portability is a later issue, but now we must get things going soonest.
    > 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 disctributed 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? Many thanks.
    > 
    > Best,
    > PANgaro
    > 

The following is the list of commercially released extended E-R,
semantic or object oriented DBMSs that I can think of off hand: G-Base
(graphael), V-base (Onto-Logic) GemStone (Servio-Logic), SIM (Unisys)
ZIM (I forgot the company but you don't want it anyways).

There are significant differences between these.  ZIM is extended E-R
and runs on PC and VAXen.  It is probably useless to you.  G-Base you
know about.  GemStone is persistent Smalltalk; it runs on Vaxen, SUNs in
a server-requester architecture like Statice.  It could be real pain to
port Flavors to that.  SIM is blindingly fast; on the biggest A series
multiprocessor mainfaime, it can do about 1,000 transactions per TP1
benchmark.  It also has very sophisticated site operation capabilities.
It is a fully industrial strength DBMS.  None of the others are.  The rub
is, it runs on a Unisys mainframe under MCP.  It will be available under
UNIX in 1991 at the earliest and has no Lisp interface.  I don't know
much about V-base, so I'll keep quiet.

There are numerous university prototypes and one from well known
research consortium: most of them are neat, but they are generally very
buggy, and features come and go every month.

Than there is vapor-ware:  depending on who you listen to, theirs is the
best.  We have tried a few of these.   One highly touted *almost beta*
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
take 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*.] 

So the only oo-dbms that I know to be Flavors compatible is Statice.  I
can also say that it 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, fast
enough to do real work now, and should get better as CPU, disk and
software improves.

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

If you really want to deliver on this, demand [DEMAND] that Symbolics
improve the maintainability and tunability of the system. 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.]

that's all for now, its weekend

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

attila@bellcore.com