

Ask YC: Getting started with OODB - icey

With all of the talk going on about MagLev, I'm realizing I'm a bit out of touch with OODB. Does anyone have any good recommendations on where to get started? I'd like to evaluate it for myself, but I don't see a standard OODB setup that people are using for themselves.<p>Any recommendations?
======
alexstaubo
Part of the reason for there not being a "standard" setup is that there are
tons of OODBs, and they are all implemented a little differently.

Some of the major ones are Objectivity/DB, Versant, ObjectStore, GemStone
(which comes in Smalltalk and Java flavours, where the former is a more mature
and flexible product) and InterSystems Caché. Caché is the odd one out; it's
object database as well as an SQL database as well as a MUMPS app server, and
while it has plenty of support for things like Java and .NET, it's
fundamentally a MUMPS system. To most of today's programmers it smells a bit
weird.

OODBs have traditionally been intimately tied to the language you write your
application in because they usually attempt to seamlessly add persistence as
an extension of the application's object model: that is, when you create
normal language objects in RAM, they become persistent on disk. As a result,
you tend to pick an OODB based on the language you use, and once you've picked
the OODB, you tend to stick with that language.

OODBs started out with C++, but automatic persistence was quite awkward and
necessitated inheriting your classes from the OODB's own class libraries and
doing a lot of calls to the OODB runtime. The OODB firms quickly latched onto
Java when it became a serious contender in the late 90s. The reason is simple:
It's really easy to make persistence transparent and elegant in Java. OODBs
typically provide post-processing tools that munge the Java bytecode --
disassembling your code and adding persistence calls.

With persistence in place, all you have to do is set up a schema (typically by
letting the OODB tools "sniff" your classes) and then add transaction code to
your app. For all the transparency, it's actually a bit invasive, and OODBs
are typically very strict about accessing instances in a transactional
context. You generally don't store long-lived references to objects, and there
are special requirements for sending objects to other threads.

As for specific products, I was never happy with any of the OODBs I tried back
in the late 1990s. Objectivity and GemStone seem like the most mature ones,
but they never provided evaluation versions so I could not try them out;
they've got the enterprise bug, so they're expensive and not very open in
terms of documentation, code availability and so on. In fact, you will have to
turn a few stones on the GemStone site to even find the GemStone OODB
products. If you are interested in MagLev you might want to look at
GemStone/S, since it's essentially the same thing.

For Smalltalk there is also the open-source Magma database, which sounds
promising. For Java there is an interesting open-source project called Neo
(<http://www.neo4j.org/>), a "netowrk database" which unlike the
aforementioned OODBs don't actually attempt to integrate with your
application's object space; instead, you create Node objects and attach
attributes to them programmatically. If you're going down this route there's
also CouchDB, a pure-data "document database".

~~~
icey
I think this might seriously be one of the most helpful replies I've seen on
YC - Thank you!

~~~
alexstaubo
You're welcome!

