web-dev-qa-db-fra.com

Des clés étrangères en mongo?

enter image description here

Comment concevoir un tel schéma dans MongoDB? Je pense qu'il n'y a pas de clé étrangère!

sqlmongodbforeign-keysnosql
78
Mark Pegasov

Vous voudrez peut-être utiliser un ORM comme Mongoid ou MongoMapper.

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

Dans une base de données NoSQL telle que MongoDB, il n'y a pas de "tables", mais des documents. Les documents sont regroupés dans des collections. Vous pouvez avoir n'importe quel type de document - avec n'importe quel type de données - dans une seule collection. En gros, dans une base de données NoSQL, c'est à vous de décider comment organiser les données et leurs relations, le cas échéant.

Ce que Mongoid et MongoMapper font est de vous fournir des méthodes pratiques pour établir des relations assez facilement. Consultez le lien que je vous ai donné et demandez n'importe quoi.

Modifier:

En mongoid vous écrirez votre schéma comme ceci:

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

Modifier:

> 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" }

Vous pouvez utiliser cet ObjectId pour établir des relations entre des documents.

23
Nerian

Comment concevoir une table comme celle-ci dans mongodb?

Tout d’abord, clarifier certaines conventions de nommage. MongoDB utilise collections au lieu de tables.

Je pense qu'il n'y a pas de clé étrangère!

Prenez le modèle suivant:

student
{ 
  _id: ObjectId(...),
  name: 'Jane',
  courses: [
    { course: 'bio101', mark: 85 },
    { course: 'chem101', mark: 89 }
  ]
}

course
{
  _id: 'bio101',
  name: 'Biology 101',
  description: 'Introduction to biology'
}

Clairement, la liste de cours de Jane pointe vers des cours spécifiques. La base de données n'applique aucune contrainte au système (, c'est-à-dire: contraintes de clé étrangère ); il n'y a donc pas de "suppressions en cascade" ni de "mises à jour en cascade". Cependant, la base de données contient les informations correctes.

De plus, MongoDB a un standard DBRef qui aide à normaliser la création de ces références. En fait, si vous regardez ce lien, il présente un exemple similaire.

Comment puis-je résoudre cette tâche?

Pour être clair, MongoDB n’est pas relationnel. Il n’existe pas de "forme normale" standard. Vous devez modéliser votre base de données en fonction des données que vous stockez et des requêtes que vous souhaitez exécuter.

59
Gates VP

De Le Petit Livre MongoDB

Une autre alternative à l'utilisation des jointures consiste à dénormaliser vos données. Dans le passé, la dénormalisation était réservée au code sensible aux performances ou lorsque les données devaient être instantanées (comme dans un journal d'audit). Cependant, avec la popularité sans cesse croissante de NoSQL, dont beaucoup n’ont pas de jointures, la dénormalisation dans le cadre de la modélisation normale devient de plus en plus courante. Cela ne signifie pas que vous devez dupliquer chaque information dans chaque document. Cependant, plutôt que de laisser la peur des données en double guider vos décisions de conception, envisagez de les modéliser en fonction des informations appartenant à quel document.

Alors,

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

S'il s'agit d'une donnée d'API RESTful, remplacez l'ID de cours par un lien GET vers la ressource de cours.

15
ZAky

Nous pouvons définir le soi-disant foreign key dans MongoDB. Cependant, nous devons maintenir l’intégrité des données PAR NOUS-MÊMES. Par exemple,

student
{ 
  _id: ObjectId(...),
  name: 'Jane',
  courses: ['bio101', 'bio102']   // <= ids of the courses
}

course
{
  _id: 'bio101',
  name: 'Biology 101',
  description: 'Introduction to biology'
}

Le champ courses contient _ids de cours. Il est facile de définir une relation un à plusieurs. Cependant, si nous voulons récupérer les noms de cours de l'étudiant Jane, nous devons effectuer une autre opération pour extraire le document course via _id.

Si le cours bio101 _ est supprimé, nous devons effectuer une autre opération pour mettre à jour le champ courses du document student.

Plus: Conception de schéma MongoDB

La nature typée des documents de MongoDB permet de définir de manière flexible les relations. Pour définir une relation un à plusieurs:

Document incorporé

  1. Convient pour un-à-quelques-uns.
  2. Avantage: pas besoin d'effectuer des requêtes supplémentaires sur un autre document.
  3. Inconvénient: impossible de gérer l'entité des documents incorporés individuellement.

Exemple:

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

Référencement enfant

Comme l'exemple student/course ci-dessus.

Parent référence

Convient aux personnes avec des milliards, telles que les messages de journal.

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
}

Virtuellement, un Host est le parent d'un logmsg. Faire référence à Host id permet de gagner beaucoup d’espace, car les messages du journal sont des milliers de milliards.

Les références:

  1. 6 Règles de base pour la conception de schémas MongoDB: Partie 1
  2. 6 Règles de base pour la conception de schéma MongoDB: Partie 2
  3. 6 Règles de base pour la conception de schémas MongoDB: Partie
  4. Modèle de relations un-à-plusieurs avec des références de documents
13
Joy