con MongoDB (y supongo que otras Api de base de datos NoSQL que se precie) las formas de consultar la base de datos son mucho más simplista de SQL. No es tedioso consultas SQL para generar y tal. Por ejemplo, toma esto de mongodb-csharp:

using MongoDB.Driver; 
Mongo db = new Mongo(); 
db.Connect(); //Connect to localhost on the default port. 
Document query = new Document(); 
query["field1"] = 10; 
Document result = db["tests"]["reads"].FindOne(query); 
db.Disconnect();

¿Cómo podría un ORM incluso simplificar que? Es un ORM o de otros «abstracción de base de datos de dispositivo» requerido en la parte superior de un decente NoSQL API?

  • Por cierto, que tipo de paliada el paréntesis comentario en mi respuesta, pero no dijo «otras Api de base de datos NoSQL que se precie» – MongoDB es muy diferente de algo como bigtable o cassandra, y consultas de/asignación en contra de los almacenes de datos tienden a ser mucho más difícil de SQL. Imaginar la implementación de un todo basado en datos de la aplicación con nada pero Dictionary<,> instancias. No es tan malo, pero está cerca.
  • bueno, por supuesto, con una clave-valor de la base de datos, la API es muy simplista. A lo que me refería por la pena-su-sal es que usted no tiene que generar su propio JSON consultas o similares de bajo nivel de las cosas.
  • ¿No es eso precisamente lo que es un asignador de qué? Estas características no están integradas, ni siquiera en Mongo.
  • hm… supongo que puede ser correcta
InformationsquelleAutor Earlz | 2010-04-22

6 Comentarios

  1. 21

    Bueno, sí, Objeto-Relacional cartógrafos son redundantes con MongoDB porque MongoDB no es un relacional de la base de datos, es un Documento Orientado a la base de datos.

    Así que en lugar de SQL, escribir consultas en JSON. A menos que usted realmente, realmente quiero escribir raw JSON, como, decir, Linq, a continuación, usted todavía va a querer usar un mapper. Y si usted no desea crear acoplamiento en contra de MongoDB en sí, entonces usted no desea pasar reales Document de los objetos de alrededor, a los que desee asignar a real POCOs.

    La asignación es mucho más fácil con un documento orientado a la DB como MongoDB, porque se han anidado los documentos en lugar de las relaciones, pero eso no significa que desaparece por completo. Eso sólo significa que hemos sustituido un tipo de «desajuste de impedancia» para un diferente, un poco menos dramático desajuste.

    • Lo que existen marcos para hacer esta asignación?
    • Creo que Norma es el único que realmente vale la pena molestarse por el momento. Eso puede cambiar en un año o dos.
    • Su respuesta esquiva el problema de que la pregunta se refiere – que es entender la necesidad de un mayor nivel de abstracción que un ORM proporciona. Como RDBMS, documento orientado a bases de datos necesarias para almacenar las relaciones entre las entidades. Como se indicó en la introducción a MongoDB docs (docs.mongodb.org/manual/core/data-modeling-introduction), es necesario elegir entre la incrustación de datos relacionados o hacer referencia a otros documentos. Documentos relacionados con la necesidad de las consultas posteriores, similar a la carga diferida en el Marco de la Entidad. Un ORM sería de gran ayuda en la simplificación de este, así como EF simplifica las combinaciones de SQL.
    • Yo no estaba «esquivando» nada, y no estoy de acuerdo en que la abstracción de esta distancia en MongoDB sería una buena idea, ya que se podría animar a los desarrolladores a modelo de datos relacional de moda cuando el modelado de datos es la más importante preocupación – como la página que enlaza claramente señala. Relacionados con la carga de los documentos uno por uno los puede matar rendimiento, cuando la mayoría de estas bases de datos han de soporte de primera clase para minimizar los viajes de ida y vuelta. Algunos, como RavenDB, incluso el apoyo de consulta de lotes y la relación de carga, lo que hace que la carga diferida automática incluso peor idea. No me gustaría ver ese tipo de «ORM».
    • El uso de un ORM es nunca óptimamente eficiente, ni siquiera para SQL. Ese no es el punto de un ORM. El punto es hacer que sea fácil para manejar información (y de seguridad) a través de los objetos. Si desea óptima, siempre tiene que escribir las consultas nativas, a menos que usted está haciendo algo increíblemente simple.
  2. 2

    Creo que un «ORM» en MongoDb puede ser útil, no sólo para «registrar» y «la deserialización de objetos» en la db (Norma parece hacer un gran trabajo), sino también por lo que es más fácil de ejecutar consultas de agregación.

    Es bueno si un «ORM» puede generar trabajos de MapReduce para la agrupación y la detección de duplicados. Algunas personas han escrito código para convertir automáticamente una instrucción sql en un trabajo mapreduce: http://rickosborne.org/blog/index.php/2010/02/19/yes-virginia-thats-automated-sql-to-mongodb-mapreduce/

  3. 1

    Otra solución es PlayOrm que puede hacer une así cuando sea necesario con Escalable-lenguaje SQL(sólo añade un prefijo a la normalidad SQL básicamente para añadir partición info).

  4. 0

    Todo lo que realmente necesita es un serializador/deserializer para hacer este trabajo.

    Norma ha hecho un gran trabajo de hacer precisamente eso. Hace que sea más fácil tomar directamente los objetos poco y acaba de salvar a mongo con una sola línea de código.

    Que ellos llaman la Norma de un ORM, pero es realmente sólo un poco de diccionario mongo contenedor.

    Un orm es extra ceremonia para estas operaciones. Si los datos de las operaciones se abstrae en un repositorio, que va a ser un no-problema, de cualquier manera, debido a la conversión a otro almacén de respaldo es un objeto por objeto, base.

    • Que llama a la Norma un ORM? Pensé que era un acrónimo recursivo para «No un Object Relational Mapper». O tal vez es simplemente «No Relational Mapper», desde la «o» está en minúscula. De cualquier manera, definitivamente no es un ORM!

Dejar respuesta

Please enter your comment!
Please enter your name here