Clés étrangères en mongo?
Comment puis-je concevoir un schéma tel que celui-ci dans MongoDB? Je pense qu'il n'y a pas de clés étrangères!
4 réponses
Vous pourriez être intéressé à utiliser 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 documents. Les Documents sont regroupés dans des Collections. Vous pouvez avoir toute sorte 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 ses relations, s'il y en a.
Quelle Mongoïde et MongoMapper faire est de vous fournir des méthodes pratiques pour mettre en place des relations assez facilement. Consultez le lien que je vous ai donné et demander quelque chose.
Modifier:
Dans mongoid, vous allez écrire 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 faire des relations entre les documents.
Comment concevoir une table comme celle-ci dans mongodb?
Tout d'Abord, pour clarifier certaines conventions de nommage. MongoDB utilise collections au lieu de tables.
Je pense qu'il n'y a pas de clés étrangères!
Prendre 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'
}
La liste des cours de Jane indique clairement certains cours spécifiques. La base de données n'applique aucune contrainte au système (c'est-à-dire: contstraints de clés étrangères), 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.
De plus, MongoDB a une norme dbref {[21] } qui aide à normaliser la création de ces références. En fait, si vous jetez un oeil à ce lien, il a un exemple similaire.
Comment puis-je résoudre cette tâche?
Pour être clair, MongoDB n'est pas relationnel. Il n'y a pas de norme "forme normale". Vous devez modéliser votre base de données en fonction des données que vous stockez et des requêtes que vous avez l'intention d'exécuter.
Une autre alternative à l'utilisation des jointures consiste à dénormaliser vos données. Historiquement, la dénormalisation était réservée aux code sensible aux performances, ou lorsque les données doivent être instantanées (comme dans un journal d'audit). Cependant, avec le toujours- 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 commun. Cela ne signifie pas que vous devez dupliquer chaque morceau de informations dans chaque document. Cependant, plutôt que de laisser la peur des données dupliquées conduire vos décisions de conception, envisagez de modéliser vos données en fonction de ce que l'information appartient à quel document.
Donc,
student
{
_id: ObjectId(...),
name: 'Jane',
courses: [
{
name: 'Biology 101',
mark: 85,
id:bio101
},
]
}
Si c'est une donnée D'API RESTful, remplacez l'id de cours par un lien GET vers la ressource de cours
, 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 courses champ 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 récupérer le document course via _id.
Si le cours bio101 est supprimé, nous devons effectuer un autre opération de mise à jour du champ courses dans le document student.
Plus: Conception De Schéma MongoDB
La nature typée par document de MongoDB prend en charge des méthodes flexibles pour définir les relations. Pour définir une relation un à plusieurs:
Document intégré
- Convient pour un à quelques-uns.
- Avantage: pas besoin d'effectuer des requêtes supplémentaires à un autre document.
- inconvénient: impossible de gérer l'entité des documents intégré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 le student/course exemple ci-dessus.
Référencement Parent
Convient pour un à squillions, tels 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
}
Pratiquement, un host, qui est le parent d'un logmsg. Le référencement à l'id host économise beaucoup d'espace étant donné que les messages de journal sont des squillions.
Références: