[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
object databases for symbolics
>From: email@example.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.
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
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
DataBase and Systems Research Group
Bellcore, scenic New Joyzee