Clés étrangères dans Mongo ?

Question

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

Answer 1

Comment concevoir une table comme celle-ci dans mongodb ?

Tout d'abord, il convient de clarifier certaines conventions de dénomination. MongoDB utilise collections au lieu de tables .

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

Prenons 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'
}

Il est clair que la liste de cours de Jane renvoie à certains cours spécifiques. La base de données n'applique aucune contrainte au système ( c.-à-d. : contraintes de clé étrangère ), il n'y a donc pas de "suppressions en cascade" ou de "mises à jour en cascade". Cependant, la base de données contient les informations correctes.

En outre, MongoDB dispose d'un Norme DBRef qui permet de normaliser la création de ces références. En fait, si vous jetez un coup d'œil à ce lien, vous y trouverez 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 comptez exécuter.

Answer 2

Vous pouvez être intéressé par l'utilisation d'un ORM comme Mongoid ou MongoMapper.

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

Dans une base de données NoSQL comme MongoDB, il n'y a pas de "tables" mais des collections. 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. Fondamentalement, 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.

Mongoid et MongoMapper proposent des méthodes pratiques pour établir des relations assez facilement. Consultez le lien que je vous ai donné et demandez ce que vous voulez.

Edit :

Dans 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

Edit :

> 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 afin d'établir des relations entre les documents.

Answer 3

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

El courses Le champ contient _id de cours. Il est facile de définir une relation de type "un à plusieurs". Cependant, si nous voulons récupérer les noms de cours des étudiants Jane nous devons effectuer une autre opération pour récupérer l'adresse de l'utilisateur. course document via _id .

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

Plus : Conception des schémas de MongoDB

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

Document incorporé

1. Convient pour une à deux personnes.
2. Avantage : il n'est pas nécessaire d'effectuer des requêtes supplémentaires sur un autre document.
3. Inconvénient : ne peut pas gérer individuellement l'entité des documents intégrés.

Ejemplo:

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 des enfants

Comme le student / course exemple ci-dessus.

Référencement des parents

Convient pour un à plusieurs millions, comme les messages du 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 . Référence à la host id permet de gagner beaucoup d'espace étant donné que les messages du journal sont des squillions.

Références :

1. 6 règles d'or pour la conception de schémas MongoDB : 1ère partie
2. 6 règles d'or pour la conception de schémas MongoDB : Partie 2
3. 6 règles d'or pour la conception de schémas MongoDB : 3ème partie
4. Modélisation des relations un-à-plusieurs avec des références de documents

Answer 4

Desde Le petit livre de MongoDB

Une autre alternative à l'utilisation des jointures consiste à dénormaliser vos données. Historiquement, la dénormalisation était réservée au code sensible aux performances, ou lorsque les données doivent être instantanées (comme dans un journal d'audit). Cependant, avec la popularité croissante de NoSQL, de nombreux Cependant, avec la popularité 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. de plus en plus courante. Cela ne signifie pas que vous devez dupliquer chaque élément d'information dans chaque document. Cependant, Cependant, plutôt que de laisser la peur de la duplication des données guider vos décisions de conception, envisagez de modéliser vos données en fonction des informations qui appartiennent à chaque document. informations appartiennent à tel ou tel document.

Donc,

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

S'il s'agit de données RESTful API, remplacez l'identifiant du cours par un lien GET vers la ressource du cours.

Answer 5

Réponse courte : Vous devez utiliser des "références faibles" entre les collections, en utilisant les propriétés ObjectId :

Les références stockent les relations entre les données en incluant des liens ou des références d'un document à un autre. Les applications peuvent résoudre ces références pour accéder aux données correspondantes. En gros, il s'agit de modèles de données normalisés.

https://docs.mongodb.com/manual/core/data-modeling-introduction/#references

Bien entendu, cela ne vérifiera pas l'intégrité référentielle. Vous devez gérer les "liens morts" de votre côté (au niveau de l'application).