Ask YC: Object databases

Sorry, you're in the wrong decade; the OODB people are now working on XMLDBs (or sometimes RDF triple stores).

GemStone is an amazing piece of software - think transactional, distributed, transparently persistent dynamic language VM. For DabbleDB we rolled our own OODB because the GemStone licensing was too steep, but they're loosening that up and I'd take a serious look at it if I were starting something new.

OODBs sound like a great idea in theory, but I've yet to meet a good OODB in practice.<p>Just use an RDBMS and in your application use a layer which abstracts away the "relational" part of the RDBMS and exposes it as objects to the rest of the application. This /can/ get a bit tricky with transactions and etc, but your internal data layer can be designed with some notion of transactions.

I think the attractions of object databases are: - It's easier to restructure than a relational schema in isolation - ORMs can be painful if you want to work like that.<p>But I think they're inherently slower for things like reporting.<p>The first item can be overcome with effective scripting (rather than trying to avoid the change necessary to restructure apps and schemas using relational databases instead embrace it and make schema changes easy) environment. And there are some OOs around that do a pretty good job of the second item (cayenne but I'm looking for one . I have had great experiences with using business logic layers around cayenne and have been able to rapidly refactor to achieve major schema changes like this.<p>Having said that - the allegro graph stuff looks like it might be a good alternative.<p>I'm currently interested in the idea of using couchdb while getting an app set up and then switching to postgresql later. Can anyone see any benefits or problems with this approach?

I've worked with CODASYL network databases, which are essentially the same as object databases (except no storage of methods in the database, which most OO databases don't do either). <p>Pros: - very fast for queries/updates along the designed network paths.<p> Downsides:<p>- not necessarily fast if network path is complex,<p>- proprietary API,<p>- corruption can be difficult to impossible to fix,<p>- corruption _does_ occur,<p>- depending on data structures used, DB may need re-organization (resizing),<p>- design requires skill: not easy to redesign or modify once deployed.<p>While fun to work with, I would hesitate to recommend using such a database unless absolutely necessary. Relational databases are much easier to set up, reconfigure, query and update. These characteristics alone usually preclude the use of an object database.

The only one I've used is ZODB. The database was fine, I guess, but the Zope stack is huge and scary.<p>I can say that when it came time to move things to another non-Zope system (a pile made up of trac, Moin Moin, Virtualmin, and other bits and pieces), it was painful to the point of ridiculousness. I'm sure ZODB masters can write middleware for that sort of thing without pain (and if you're building your system that uses the ODB from scratch, you'll probably understand it well enough to do so). But I'll stick with standard cubbies in which to shove my things from now on (standard, to me, means flat files or an SQL database, as requirements dictate).

There's one approach to OO databases which is seems interesting to me. It's called SBA (Stack Based Approach) and the corresponding query language is called SBQL. It's been a subject of academic research in Poland for quite a while now, they've published a number of papers and a book on the subject, but only recently they actually got to implementing the thing. The project's web page is <a href="http://loxim.mimuw.edu.pl/" rel="nofollow">http://loxim.mimuw.edu.pl/</a> It is still rather immature and the English documentation is definitely incomplete, but in my opinion there is a (small) chance that this could grow into something big and useful.

I played with a fair number of them back in the 90's. ObjectStore, GemStone, etc.<p>I think these systems really only make sense in the telecommunications, CAD, etc. niches where performance is critical. <p>That said, the new trend in DB systems are main memory relational systems based on column store architectures (vs. traditional row store). The performance of such architectures is really quite promising. Go to Stonebreaker's talk at the latest VLDB in Viena.<p>Or take a look at his new company:<p><a href="http://www.streambase.com/" rel="nofollow">http://www.streambase.com/</a>

Thanks for the recommendations, I'm checking it out.

If you use Python, then I recommend Schevo.org better than ZODB to me :)

roll your own.

db4o.org