En el sitio web de MongoDB escribieron que MonogDB es una base de datos orientada a documentos, por lo que si MongoDB no es una base de datos orientada a objetos, ¿qué es? y ¿cuáles son las diferencias entre las bases de datos orientadas a documentos y objetos?¿Está MongoDB orientado a objetos?
Creo que las bases de datos orientadas a documentos y orientadas a objetos son bastante diferentes. Bastante detallado post sobre esto aquí:
base de datosUn documento orientado es un concepto diferente de objetar y bases de datos relacionales. Una base de datos de documento puede contener o no un campo, mientras que una base de datos relacional u objeto esperaría que los campos faltantes se llenen con una entrada nula.
Imagine almacenar una cadena XML o JSON en un solo campo en una tabla de base de datos. Eso es similar a cómo funciona una base de datos de documentos. Simplemente permite que los datos semiestructurados se almacenen en una base de datos sin tener muchos campos nulos.
orientados a documentos
En mi entendimiento MongoDB trata a cada registro individual como un documento no importa es 1 campo o campos n. Incluso puede tener documentos incrustados dentro de un documento. No es necesario definir un esquema que esté estrictamente controlado en otros sistemas de base de datos relacionales (MySQL, PorgeSQL, etc.). He usado MongoDB por un tiempo y realmente me gusta su filosofía.
Objeto orientado es un modelo de base de datos en el que la información se representa en forma de objetos como se usa en la programación orientada a objetos (Wikipedia).
Esto puede ser un poco tarde en la respuesta, pero creo que vale la pena señalar, hay grandes diferencias entre ODB y MongoDB.
En general, el objetivo de ODB son las referencias (relaciones) tranparent entre objetos en un modelo de dominio arbitariamente complejo sin tener que usar y administrar el código para algo así como un DBRef. Incluso si tiene un par de miles de clases, no necesita preocuparse por la administración de ninguna clave, vienen de forma gratuita y cuando crea instancias de esos 1000 de clases en tiempo de ejecución, automáticamente crean el esquema en la base de datos ... incluso para cosas como un objeto de autorreferencia con colecciones de colecciones.
Además, sus transacciones pueden abarcar estas referencias, por lo que no tiene que utilizar un modelo completamente integrado.
Los conceptos son aquellos aprovechados en soluciones ORM como JPA, el ciclo de vida persistente administrado del objeto, se toma del espacio ODB, pero la GRAN diferencia es que no hay ningún mapeo ALL en el ODB y las relaciones se almacenan como parte de la base de datos, por lo que no hay JOIN en tiempo de ejecución para resolver las relaciones, todas las relaciones se resuelven con la misma velocidad que la búsqueda de un árbol b. Para aquellos de ustedes que han usado Hibernate, imaginen Hibernate sin CUALQUIER archivo de mapeo y órdenes de magnitud más rápido porque no hay tiempo de ejecución JOIN detrás de escena.
Además, ODB permite consultas a través de cualquier relación en su modelo, por lo que no está restringido a consultas en una colección en particular como lo es en MongoDB. Por supuesto, los índices hash/b-tree/aggregate son compatibles, por lo que las consultas son muy rápidas cuando se usan.
Puede evolucionar instancias de cualquier clase en un ODB en el nivel de clase y en el tiempo de ejecución se resuelve la versión de clase correcta. Muy diferente de la forma en que funciona en MongoDB manteniendo el código para decidir cómo lidiar con las diversas formas de blob (u objeto de valor) que resultan de desarrollar una base de datos sin esquema ... o escribir el código para visitar y cambiar cada objeto de valor porque usted quería cambiar el esquema
En lo que respecta a la separación, creo que es mucho más fácil decidir sobre un modelo de partición para un modelo de dominio que puede hablar sobre objetos arbitrarios, entonces es para descubrir la estrategia de integración total. para su colección contenía documentos en MongoDB. Como un ejemplo ridículo, usted tiene un Contacto y una Dirección y un ShoppingCart y estos están relacionados en un documento JSON y usted decide realizar una partición en el Contacto por Contact_id. No hay absolutamente nada que le impida tratar esas 3 clases como solo objetos en lugar de documentos JSON y almacenarlos con una partición en Contact_id tal como lo haría con MongoDB. Sin embargo, si tenía otra cuenta objetiva y deseaba administrarla de forma no integrada debido a algunas operaciones de facturación agregadas en las cuentas, puede tenerla gratis (no es necesario crear código para un tipo DBRef) en la ODB. ... y puede optar por la partición junto con el Contacto o elegir almacenar las Cuentas en un nodo físico completamente separado, sin embargo, todo estará conectado en tiempo de ejecución en el espacio de la aplicación ... al igual que la magia.
Si desea ver un video realmente genial sobre cómo crear una aplicación con un ODB que muestre la distribución, el movimiento del objeto, la tolerancia a fallas, la optimización del rendimiento ... vea esto (si desea saltar a la parte más interesante, salte unos 21 minutos y se evitará la construcción de la aplicación y simplemente ver el lo fácil que es añadir la distribución y la tolerancia a fallos de cualquier aplicación existente):
Gracias Robert por su respuesta, muy clara y útil. – Amer
un poco de un comentario tarde en una antigua respuesta, pero mi entendimiento también es que realmente no se pueden aplicar restricciones en las transacciones que abarcan muchas entidades/documentos diferentes. Por ejemplo, una operación de débito de una cuenta bancaria que luego acredita esa cantidad a otra. –