

Ask YC: Object databases - robmnl

Has anyone played with OO db's?<p>Which did you like and why?
======
wmf
Sorry, you're in the wrong decade; the OODB people are now working on XMLDBs
(or sometimes RDF triple stores).

~~~
imasr
It's like electric cars. As long there's some oil out there, no one will find
them feasible.

~~~
wmf
So when does "peak SQL" kick in?

------
avibryant
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.

------
jey
OODBs sound like a great idea in theory, but I've yet to meet a good OODB in
practice.

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.

~~~
avibryant
Abstracting away the "relational" part of the RDBMS sounds like a great idea
in theory, but I've yet to meet a good O/R mapping layer in practice.

What I _have_ met is several IT projects that have failed thanks to inordinate
amounts of resources sunk into O/R mapping issues...

~~~
corentin
> Abstracting away the "relational" part of the RDBMS sounds like a great idea
> in theory [...]

Abstracting away a model doesn't sound like a great idea to me.

~~~
jey
Ever programmed in a "Higher Level Language"? The model of register-based
computation has been abstracted away! Seems OK to me.

------
cratuki
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.

But I think they're inherently slower for things like reporting.

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.

Having said that - the allegro graph stuff looks like it might be a good
alternative.

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?

~~~
ijoshua
"But I think they're inherently slower for things like reporting."

I wouldn't say the deficiency is _inherent_, but the powerful indexing ability
of a relational DB that we take for granted seems to be necessarily _ad hoc_
in an object-oriented DB. From my understanding, the index in an OODB is just
another object in the database, which may be a B-tree, a hash table, or a
simple sequential list. So far, that's fairly similar to the RDB. However, the
indices in the RDB are closely coupled to the table that stores the records.
The RDB "knows" that it should update the index when the table is modified. On
the other hand, there isn't a table of records in the OODB, so there isn't a
close coupling of the index to the data store. It may be entirely up to the
application to manage the integrity of the index.

------
mdkersey
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).

Pros: \- very fast for queries/updates along the designed network paths.

Downsides:

\- not necessarily fast if network path is complex,

\- proprietary API,

\- corruption can be difficult to impossible to fix,

\- corruption _does_ occur,

\- depending on data structures used, DB may need re-organization (resizing),

\- design requires skill: not easy to redesign or modify once deployed.

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.

------
SwellJoe
The only one I've used is ZODB. The database was fine, I guess, but the Zope
stack is huge and scary.

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).

------
pfedor
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 <http://loxim.mimuw.edu.pl/> 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.

------
anaphoric
I played with a fair number of them back in the 90's. ObjectStore, GemStone,
etc.

I think these systems really only make sense in the telecommunications, CAD,
etc. niches where performance is critical.

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.

Or take a look at his new company:

<http://www.streambase.com/>

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

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

------
tricky
roll your own.

------
schismahaese
db4o.org

