En el límite: una discusión entre RDBMS y OODBMS

El 4 de enero, en comp.object, Frebe lanza una pregunta que abrió una discusión acalorada que no terminará rápidamente:

In the OO world, there has been talking about OO databases for about 15 years now. But to me it is still not clear what a OO database actually is?

Sometimes people talk about OO databases as "a database that can do everything a relational database can, plus extra OO things". Sometimes they seem not to support the relational model and seem to be very closeto the network model. Sometimes hierarchial databases (like XML databases) are referred as "OO databases".

My question is: Which are the most popular OODBMS and what are their main features in comparison to relational databases? Does they have a query language and in that case, how does it work?

Sometimes I read that OO databases have a "seamless" integration with the programming language. Does this mean that the separation of database access logic into a persistence layer is not more necessary, or?

Fredrick desató vientos furiosos, pero muy útiles para navegar en el límite de las vías para manejar datos, objetos, o "persistencia", para decirlo de una manera que promedie lo que se puede obtener en el modelo relacional y en el de objetos. Me inclino a compartir la opinión de aquellos que consideran a las bases de datos orientadas a objeto "una mala idea cuyo tiempo nunca llega" (Daniel Parker). Así como Simon Williams puntualiza flancos débiles de las bases de datos relacionales, esta discusión pone sobre la mesa las fronteras donde el procesamiento de la persistencia y de la volatilidad no encuentra un medio consistente de representarlo o manejarlo.
Sin embargo, las observaciones de las dificultade de las OODB expresadas por sus propios usuarios o abogados más o menos defensores, parecen confirmar que esta vía está casi muerta:

The main advantage is that they provide very convenient syntax for accessing objects and they automate a lot of access details so the developer never really has to think very much about persistence. The downside is that the database boilerplate is ubiquitous in the application; typically even the 'new' operator is overridden to provide housekeeping infrastructure for the OODB activities. So the application code is tightly married to the specific DB vendor. Another disadvantage is that if one needs to access the same data from different applications, the stored data must be a one-size-fits-all representation of the object model, which is rarely very practical for complex OO applications. (H.S.Lahman)

Considering how much time and code programmers spend trying to figure out how best to store their data, and OODBMS' ability to make memory seem infinite and remove the burden of how persistence is achieved from the programmer is a goodthing. The estimates of 25% of application code dealing with database stuffs is about right. When we converted our application from RDB to OODBMS we saw a 22% reduction in code.

The greatest drawback is the lack of a query language and perhaps the impossibility of creating one to query data graphs (which is what OODBMS seem to be). Though our core application saw a 22% reduction in code 75% of any
system is typically queries and reports. Having to write them in the OODBMS'
language is a great way to slow development to a crawl. Adhoc queries is something SQL excels at, not to mention all the available report writers that simply don't exist for OODBMS. (Thomas Gagne)

La defensa más consistente de las OODB proviene de AndyW:

In an OODB you dont have database access logic, there is no need for it - and thats a mechanism provided by OO itself, rather than a database.

An OODB stores the instance of an object along with all the code needed to work with that instance. The location of the object is irrelevant to its usage - wether its on disk, in memory or on amachine in a different country is not important.

Objects have what is called an Object ID or OID for short. Think of it like a name tag for the object and it must be unique - just like an object is in the real world. Just like your coffee cup is unique. Also objects may have many OIDs - just like your cup can have manynames.

Objects are complex entities and can be made up of smaller simpler or complex objects themselves. When you deal with a complex object you also automatically deal with its individual parts thru the power of polymorphism and encapsulation. This is why OODBs are very good when used for diagramatic parts catalogs and telephone exchanges (phonecall info is very complex containing many dynamic sub parts).

Referencing an object automatically creates an instance if none exists and most OODBs will load the persistant form into transient space automatically, likewise they will persist automatically (hence no access code). Persisntance and transience mean slightly different things in OODBs as they do in normal programming, it also happens to be mostly irrelevant to the application program.

Andy fue replicado con dureza y sarcasmo...En el debate participan actores de proyectos de implantación de sistemas apoyados en OODB, que fueron abandonados por imposibilidad de concretarlos.