Ask YC: Getting started with OODB

https://news.ycombinator.com/item?id=211255

by icey • 18 years ago

4 3 18 years ago

news.ycombinator.com

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.

Any recommendations?

alexstaubo2• 18 years ago

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• 18 years ago

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

alexstaubo2• 18 years ago

You're welcome!

Ask YC: Getting started with OODB

Related Stories