4 ms·

"With the recent arrival of object-oriented databases, the industry may finally achieve some of the promises which were made 20 years ago about the capabilities

"With the recent arrival of object-oriented databases, the industry may finally achieve some of the promises which were made 20 years ago about the capabilities of computers to automate and improve organizations." um... wow... this 1 sentence discredits the entire email. Object Oriented Databases were a HUGE failure. I can't be sure but PostgreSQL might be the only surviving one, and it survived because it went relational. just my 2 cents.

jbooth 17y ago
No it doesn't.. ok, early 90s, people thought object oriented everything was the way forward. But his main point, that blasting through a flat file without a ton of row-locking and transactional overhead could satisfy a number of needs better than the actual DBMS, is still true. If you need to be transactional, on the other hand, that's a different story.
- deleted 17y ago
  [deleted]
rapind 17y ago
What's the difference between object oriented and document oriented databases? Aren't all of the recent key/value databases lately pretty much the same concept as an object database? Sorry if that's a dumb question...
- wmf 17y ago
  OODBs tend to use navigation of object graphs (see http://c2.com/cgi/wiki?NavigationalDatabase http://c2.com/cgi/wiki?NavigationalDatabase ) as the key operation, while document or key-value DBs rely more on queries.
  - rapind 17y ago
    Thanks for the link. Dug around a bit and from what I can tell they are pretty similar. Object databases have been referred to as hierarchical databases (I.e. XML data), many of the key-value databases being touted in the past couple of years seem hierarchical to me, only with some additional indexing and query language packaged on top (which you could add yourself with Lucene or Sphinx I would assume). I must be missing something, but I'll keep digging.
sfwc 17y ago
GemStone was beloved of most who used it, and it is poised to make a comeback through MagLev. Meanwhile, ORMs (which attempt to implement an OODB on top of an RDB) are ubiquitous.
simc 17y ago
PostgreSQL was not an object-oriented database, it was an object-relational database. Despite not living up to some people's exceptions that that it would replace the relational database object-oriented databases were not a "huge failure". They are useful for applications where relational databases were not suitable, for example CAD (as mentioned in the article).
shiro 17y ago
This article becomes interesting if you realize that (1) it was written in 1991 and (2) was written by a distinguished computer scientist. I think it amusing to see how smart people were thinking back then. I built a system with OODB back in late 90s. It was a pleasant experience in a way; I could walkaround inflexibility of RDBMS. RDBMS works great if your data domain can be straightforwardly represented in relational model. But if your application is inherently working on a graph, it becomes awkward to map it onto relational model. With OODB, graphs formed by objects can be directory stored. OTOH, I had a difficulty from the lack of good abstraction; ironically, implementaion of application data structure was too tightly coupled with the data storage model. Application-level implementation details could affect data storage unnecessarily, or some optimization techniques in the db side could affect the application. Relational model and SQL do give a good abstraction barrier in a sweet spot, at least for some type of applications. I think graph database will give us this nice abstraction barrier for the network-of-object type application domain. Let's see how it turns out in 20 years later...

jbooth 17y ago

No it doesn't.. ok, early 90s, people thought object oriented everything was the way forward. But his main point, that blasting through a flat file without a ton of row-locking and transactional overhead could satisfy a number of needs better than the actual DBMS, is still true. If you need to be transactional, on the other hand, that's a different story.

deleted 17y ago
[deleted]

rapind 17y ago

What's the difference between object oriented and document oriented databases? Aren't all of the recent key/value databases lately pretty much the same concept as an object database? Sorry if that's a dumb question...

wmf 17y ago
OODBs tend to use navigation of object graphs (see http://c2.com/cgi/wiki?NavigationalDatabase http://c2.com/cgi/wiki?NavigationalDatabase ) as the key operation, while document or key-value DBs rely more on queries.
- rapind 17y ago
  Thanks for the link. Dug around a bit and from what I can tell they are pretty similar. Object databases have been referred to as hierarchical databases (I.e. XML data), many of the key-value databases being touted in the past couple of years seem hierarchical to me, only with some additional indexing and query language packaged on top (which you could add yourself with Lucene or Sphinx I would assume). I must be missing something, but I'll keep digging.

sfwc 17y ago

GemStone was beloved of most who used it, and it is poised to make a comeback through MagLev. Meanwhile, ORMs (which attempt to implement an OODB on top of an RDB) are ubiquitous.

simc 17y ago

PostgreSQL was not an object-oriented database, it was an object-relational database. Despite not living up to some people's exceptions that that it would replace the relational database object-oriented databases were not a "huge failure". They are useful for applications where relational databases were not suitable, for example CAD (as mentioned in the article).

shiro 17y ago

This article becomes interesting if you realize that (1) it was written in 1991 and (2) was written by a distinguished computer scientist. I think it amusing to see how smart people were thinking back then. I built a system with OODB back in late 90s. It was a pleasant experience in a way; I could walkaround inflexibility of RDBMS. RDBMS works great if your data domain can be straightforwardly represented in relational model. But if your application is inherently working on a graph, it becomes awkward to map it onto relational model. With OODB, graphs formed by objects can be directory stored. OTOH, I had a difficulty from the lack of good abstraction; ironically, implementaion of application data structure was too tightly coupled with the data storage model. Application-level implementation details could affect data storage unnecessarily, or some optimization techniques in the db side could affect the application. Relational model and SQL do give a good abstraction barrier in a sweet spot, at least for some type of applications. I think graph database will give us this nice abstraction barrier for the network-of-object type application domain. Let's see how it turns out in 20 years later...