Las bases de datos orientadas a objetos son filosóficamente más diferentes de lo que uno podría esperar.
Tenemos una representación estandarizada documento/objeto - JSON es actualmente popular para almacenamientos orientados a documentos, quizá ODL en ODBMS. Lo bueno de JSON es que, al menos para programadores Web, es una tecnología que ya utilizan y con la que están familiarizados. No añadimos nada nuevo qué aprender.
En un documento, realmente estamos pensando en "documentos", no en objetos. Los objetos tiene métodos, esquemas predefinidos, jerarquías e herencias. Esto no está presente en una base de datos de documentos; el código no es parte de la base de datos.
Mientras que pueden existir relaciones entre documentos, los punteros entre documentos están desenfatizados. En el almacenamiento de documentos no persisten "grafos" de objetos - ésta no es una base de datos de grafos (las bases de datos de grafos son una nueva categoría NoSQL - ¿qué diferencia hay entre una base de datos de grafos y una ODBMS? Una pregunta interesante)
El diseño de esquema es importante en las bases de datos de documentos. No podemos pensar en términos de "solamente persiste lo que yo trabajo con memoria RAM desde mi programa". Todavía definimos un esquema. Este esquema puede variar con respecto a un "código de esquema" interno de la aplicación. Por ejemplo, en MongoDB tenemos colecciones (análogas a las tablas) de documentos JSON, y una declaración explícita de índices sobre campos específicos de la colección. Podemos pensar que esta aproximación tiene algunos méritos - un desacoplamiento de datos y de código. El código tiende a cambiar rápidamente.
Embeber es un concepto importante en el almacenamiento de documentos. Es mucho más común anidar datos dentro de documentos que tener referencias entre documentos.
¿Por qué desenfatizar las relaciones? Por un par de razones. La primera, con grafos arbitrarios de objetos, es difícil procesar el grafo desde un cliente sin muchos tiempos de espera cliente/servidor. Un objetivo con bases de datos de documentos es mantener el paradigma cliente/servidor y mantener código predispuesto para el cliente (no obstante con algunas excepciones como map/reduce). Segundo, un objetivo clave en el espacio "NoSQL" es la escalabilidad horizontal. Los grafos arbitrarios de objetos dificultarían la partición entre servidores de una manera que garantice el rendimiento.
Fuente: http://blog.10gen.com/post/437029788/json-db-vs-odbms
