Ask YC: Object databases
12 comments
roll your own.
Sorry, you're in the wrong decade; the OODB people are now working on XMLDBs (or sometimes RDF triple stores).
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.
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.
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.
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...
What I have met is several IT projects that have failed thanks to inordinate amounts of resources sunk into O/R mapping issues...
Object Orientation shouldn't be treated as a religion to which you must strictly adhere. You just want some useful concepts and abstractions to express your code in terms of. I don't want to see "LEFT OUTER JOIN" sprinkled through my code, as that's not a concept that is relevant to my application logic. Nor do I want to spend months implementing some idiotic "Object Oriented Design Patterns" because it's the current fad to join the Church of Object Orientation. I just aim to have some nice, clean concepts with which I can write simple and elegant code.
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.
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.
Thanks for the recommendations, I'm checking it out.
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/
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/
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.
db4o.org
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?
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?
"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.
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.
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).
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).
If you use Python, then I recommend Schevo.org better than ZODB to me :)
Which did you like and why?