tutorial query queries mongo fields sql mongodb foreign-keys nosql

sql - query - show document mongo



Claves extranjeras en mongo? (4)

¿Cómo diseñar una mesa como esta en mongodb?

Primero, aclarar algunas convenciones de nombres. MongoDB usa collections lugar de tables .

¡Creo que no hay claves extranjeras!

Tome el siguiente modelo:

student { _id: ObjectId(...), name: ''Jane'', courses: [ { course: ''bio101'', mark: 85 }, { course: ''chem101'', mark: 89 } ] } course { _id: ''bio101'', name: ''Biology 101'', description: ''Introduction to biology'' }

Claramente, la lista de cursos de Jane apunta a algunos cursos específicos. La base de datos no aplica ninguna restricción al sistema ( es decir, contstraints de clave externa ), por lo que no hay "eliminaciones en cascada" o "actualizaciones en cascada". Sin embargo, la base de datos contiene la información correcta.

Además, MongoDB tiene un estándar DBRef que ayuda a estandarizar la creación de estas referencias. De hecho, si echas un vistazo a ese enlace, tiene un ejemplo similar.

¿Cómo puedo resolver esta tarea?

Para ser claros, MongoDB no es relacional. No hay una "forma normal" estándar. Debe modelar su base de datos de acuerdo con los datos que almacena y las consultas que desea ejecutar.

¿Cómo diseño un esquema como este en MongoDB? ¡Creo que no hay claves extranjeras!


Del libro The Little MongoDB

Otra alternativa más al uso de combinaciones es desnormalizar sus datos. Históricamente, la desnormalización se reservó para código sensible al rendimiento, o cuando los datos deberían ser instantáneos (como en un registro de auditoría). Sin embargo, con la creciente popularidad de NoSQL, muchos de los cuales no tienen combinaciones, la desnormalización como parte del modelado normal es cada vez más común. Esto no significa que deba duplicar cada pieza de información en cada documento. Sin embargo, en lugar de dejar que el miedo a la duplicación de datos impulse sus decisiones de diseño, considere modelar sus datos según la información que pertenece a cada documento.

Asi que,

student { _id: ObjectId(...), name: ''Jane'', courses: [ { name: ''Biology 101'', mark: 85, id:bio101 }, ] }

Si se trata de una información RESTful API, reemplace la identificación del curso con un enlace GET al recurso del curso.


Podemos definir la llamada foreign key en MongoDB. Sin embargo, necesitamos mantener la integridad de los datos POR NOSOTROS MISMOS . Por ejemplo,

student { _id: ObjectId(...), name: ''Jane'', courses: [''bio101'', ''bio102''] // <= ids of the courses } course { _id: ''bio101'', name: ''Biology 101'', description: ''Introduction to biology'' }

El campo de courses contiene _id s de cursos. Es fácil definir una relación de uno a muchos. Sin embargo, si queremos recuperar los nombres de los cursos de la alumna Jane , debemos realizar otra operación para recuperar el documento del course través de _id .

Si se elimina el curso bio101 , debemos realizar otra operación para actualizar el campo de courses en el documento del student .

Más: Diseño de esquema MongoDB

La naturaleza de documento de MongoDB admite formas flexibles de definir relaciones. Para definir una relación de uno a muchos:

Documento incrustado

  1. Adecuado para uno-a-pocos.
  2. Ventaja: no es necesario realizar consultas adicionales a otro documento.
  3. Desventaja: no puede administrar la entidad de documentos incrustados individualmente.

Ejemplo:

student { name: ''Kate Monster'', addresses : [ { street: ''123 Sesame St'', city: ''Anytown'', cc: ''USA'' }, { street: ''123 Avenue Q'', city: ''New York'', cc: ''USA'' } ] }

Referencia de niños

Como el ejemplo de student / course anterior.

Referencia de padres

Adecuado para one-to-squillions, como mensajes de registro.

host { _id : ObjectID(''AAAB''), name : ''goofy.example.com'', ipaddr : ''127.66.66.66'' } logmsg { time : ISODate("2014-03-28T09:42:41.382Z"), message : ''cpu is on fire!'', host: ObjectID(''AAAB'') // Reference to the Host document }

Virtualmente, un host es el padre de un logmsg . La referencia a la id del host ahorra mucho espacio dado que los mensajes de registro son squillions.

Referencias

  1. 6 Reglas de oro para el diseño del esquema MongoDB: Parte 1
  2. 6 Reglas de oro para el diseño del esquema de MongoDB: Parte 2
  3. 6 Reglas para el diseño del esquema MongoDB: Parte 3
  4. Relaciones modelo uno a muchos con referencias de documentos

Puede que le interese usar un ORM como Mongoid o MongoMapper.

http://mongoid.org/docs/relations/referenced/1-n.html

En una base de datos NoSQL como MongoDB no hay ''tablas'' sino documentos. Los documentos se agrupan dentro de Colecciones. Puede tener cualquier tipo de documento, con cualquier tipo de datos, en una sola colección. Básicamente, en una base de datos NoSQL depende de usted decidir cómo organizar los datos y sus relaciones, si los hay.

Lo que Mongoid y MongoMapper hacen es proporcionarle métodos convenientes para establecer relaciones con bastante facilidad. Mira el enlace que te di y pregunta cualquier cosa.

Editar:

En Mongoid escribirás tu esquema así:

class Student include Mongoid::Document field :name embeds_many :addresses embeds_many :scores end class Address include Mongoid::Document field :address field :city field :state field :postalCode embedded_in :student end class Score include Mongoid::Document belongs_to :course field :grade, type: Float embedded_in :student end class Course include Mongoid::Document field :name has_many :scores end

Editar:

> db.foo.insert({group:"phones"}) > db.foo.find() { "_id" : ObjectId("4df6539ae90592692ccc9940"), "group" : "phones" } { "_id" : ObjectId("4df6540fe90592692ccc9941"), "group" : "phones" } >db.foo.find({''_id'':ObjectId("4df6539ae90592692ccc9940")}) { "_id" : ObjectId("4df6539ae90592692ccc9940"), "group" : "phones" }

Puede usar ese ObjectId para hacer relaciones entre documentos.