Merci pour ce tuto, je m'initie en ce moment à mongodb et je le trouve donc très intéressant. Cependant, étant très habitué au modèle relationnel j'ai du mal à trouver mes repères et à trouver les bonnes pratiques.
Petite question sur le premier exemple:
Exemple :
Imaginons un blog contenant des posts, chaque post contenant des commentaires. [...]
Avec MongoDB, on va créer des documents qui contiennent un tableau de commentaires (dénormalisation) comme suit :
1
2
3
4
5
6
| {
"_id" : { "$oid" : "5143ddf3bcf1bf4ab37d9c6d" },
"body" : "Je suis un super post !",
"post_date" : { "$date" : 1363402227874 },
"comments" : [
{
"_id": 1,
"comment_text": "Je suis le commentaire 1",
"author": "Mickael Barroux"
},
{
"_id": 2,
"comment_text": "Je suis le commentaire 2",
"author": "Arolla",
}
]
} |
Cela sera optimisé pour la récupération des données en lecture. Par contre, revers de la médaille, ce sera un peu plus compliqué dans des cas de mises à jour du nom d'un auteur par exemple (il faudra mettre à jour l'auteur de chaque commentaire écrit par la personne).
Je me posais la même question en regardant le schéma de la base, comment changer le nom de l'auteur si celui ci change son pseudo. On devra boucler sur tous les messages, comparer le champs author (donc comparaison de chaine, plus lent que comparer un id). Existe il une meilleur pratique? Tout ce que je peux imaginer retombe dans un modèle relationnel...
Imaginons aussi qu'un utilisateur a une signature sur ces messages (potentiellement longue). Si la personne a 3000 messages, et qu'il décide d'en changer, on va devoir réécrire 3000 fois sa signature dans la base?
Ma deuxième question porte sur le schéma dynamique de mongodb (le fait de pouvoir rajouter des champs ou des sous collections à certains documents seulement). Comment le gérer efficacement dans son application (comment éviter d'appeler un champs qui n'existe pas)? Avez vous des exemple d'utilisation concrets de cette possibilité?
0 |
0 |
