Pas toujours, la normalisation à mort inflige des pertes de performances, mais il est vrai que personnellement, je n'applique pas la même normalisation à MongoDB qu'à SQL.
Si vous connaissez les formulaires normalisés ( http://en.wikipedia.org/wiki/Database_normalization ) J'aime penser que MongoDB passe à 1NF, puis redescend à nouveau dénormalisé.
Oh oui nous le faisons. La mise à jour est pénible si les données sont mal dupliquées.
Laissez-moi vous donner un exemple :category et product seraient deux entités distinctes, il est indéniable. Ces deux entités sont normalisées (les données répétitives de product a été séparé de category ). Une autre façon de penser est la suivante :Tous les produits n'existeront-ils que dans une seule catégorie ?
Ainsi, sur les entités de niveau supérieur, comme vous pouvez le constater, les mêmes règles s'appliquent relativement, 1NF étant facilement appliqué à MongoDB.
En ce qui concerne la duplication, vous ne voudriez bien sûr pas stocker chaque produit séparément dans chaque catégorie (j'ai répondu non à la question ci-dessus), vous voudriez donc naturellement séparer les catégories et les produits.
Vous auriez normalement une relation plusieurs-à-plusieurs ici avec une table normalisée intermédiaire. C'est là que la dénormalisation peut entrer en jeu. Vous pouvez dire qu'une catégorie aura une liste de produits qui sont uniques à cette catégorie en tant que telle, vous pouvez dénormaliser la table relationnelle plusieurs à plusieurs dans la ligne de catégorie en tant que liste (ou l'inverse dans la rangée de produits). Cela ne générera pas de duplication puisque cette liste est unique à cette catégorie (plus que probablement). Cela signifie bien sûr que la catégorie ou les produits hébergeraient une liste _id s de la ligne associée au lieu de l'objet lui-même.
Il y a des moments où la duplication est nécessaire, principalement pour l'optimisation ou les solutions de contournement pour ne pas avoir de JOINs ; cette règle s'applique également à SQL si vous avez déjà créé un site suffisamment grand.
Les scénarios d'utilisation typiques de la duplication sont les champs d'agrégation de statistiques comme les partages et les commentaires des publications Facebook et peut-être même que les 5 derniers commentaires de cette publication seraient également dupliqués sur la ligne de publication.
Il ne s'agit donc pas d'ignorer la conception du schéma, mais plutôt de l'adapter aux caractéristiques de MongoDB. Normalement, si vous faites cela, vous constaterez que vous concevez naturellement un bon schéma.
Comme référence supplémentaire, vous pouvez vous référer ici :http://docs.mongodb.org/ manuel/noyau/modélisation des données
