Vous pouvez soit concevoir un schéma dans lequel vous pouvez référencer ou intégrer des documents. Regardons la première option des documents intégrés. Avec l'application ci-dessus, vous pouvez stocker les informations dans un document comme suit :
// db.table1 schema
{
"_id": 3, // table1_id
"is_active": true,
"created": ISODate("2015-04-07T16:00:30.798Z"),
"lang": [
{
"name": "foo",
"surname": "bar",
"address": "xxx"
},
{
"name": "abc",
"surname": "def",
"address": "xyz"
}
]
}
Dans l'exemple de schéma ci-dessus, vous auriez essentiellement intégré le table1_lang informations dans le table1 principal document. Cette conception a ses mérites, l'un d'eux étant la localité des données. Étant donné que MongoDB stocke les données de manière contiguë sur le disque, le fait de mettre toutes les données dont vous avez besoin dans un seul document garantit que les disques en rotation prendront moins de temps pour rechercher un emplacement particulier sur le disque. Si votre application accède fréquemment à table1 informations avec le table1_lang données, vous voudrez presque certainement emprunter la voie intégrée. L'autre avantage des documents intégrés est l'atomicité et l'isolement des données d'écriture. Pour illustrer cela, disons que vous voulez supprimer un document qui a une clé lang "name" avec la valeur "foo", cela peut être fait avec une seule opération (atomique) :
db.table.remove({"lang.name": "foo"});
Pour plus de détails sur la modélisation des données dans MongoDB, veuillez lire la documentation Introduction à la modélisation des données , en particulier Modèle Relations un-à-plusieurs avec les documents intégrés
L'autre option de conception consiste à référencer des documents dans lesquels vous suivez un schéma normalisé. Par exemple :
// db.table1 schema
{
"_id": 3
"is_active": true
"created": ISODate("2015-04-07T16:00:30.798Z")
}
// db.table1_lang schema
/*
1
*/
{
"_id": 1,
"table1_id": 3,
"name": "foo",
"surname": "bar",
"address": "xxx"
}
/*
2
*/
{
"_id": 2,
"table1_id": 3,
"name": "abc",
"surname": "def",
"address": "xyz"
}
L'approche ci-dessus donne une flexibilité accrue dans l'exécution des requêtes. Par exemple, pour récupérer tous les enfants table1_lang documents pour l'entité parente principale table1 avec l'id 3 sera simple, créez simplement une requête sur la collection table1_lang :
db.table1_lang.find({"table1_id": 3});
Le schéma normalisé ci-dessus utilisant l'approche de référence de document présente également un avantage lorsque vous avez des relations un à plusieurs avec une arité très imprévisible. Si vous avez des centaines ou des milliers de table_lang documents par table entité, l'intégration a tellement de revers en ce qui concerne les contraintes spatiales car plus le document est volumineux, plus il utilise de RAM et les documents MongoDB ont une limite de taille stricte de 16 Mo.
La règle générale est que si le modèle de requête de votre application est bien connu et que les données ne sont généralement accessibles que d'une seule manière, une approche intégrée fonctionne bien. Si votre application interroge les données de plusieurs manières ou si vous ne parvenez pas à anticiper les modèles de requête de données, un modèle de référencement de document plus normalisé sera approprié dans ce cas.
Réf :
