Je viens de commencer à utiliser une base de données NoSQL (MongoDB) et je suis curieux de connaître les meilleures pratiques pour la conception de bases de données.
Je suppose que l'architecture devrait être différente des bases de données relationnelles? Devrais-je toujours viser une base de données normalisée?
Par exemple, j'ai un cas d'utilisation particulier;
J'ai un utilisateur avec un historique de location (tableau d'adresses) ce tableau devrait-il être un tableau sur l'utilisateur ou une collection séparée avec une clé partagée?
Réponses:
Une approche appropriée pour la conception de la base de données NoSQL est une DDD ( Domain Driven Design ). Pour certaines personnes qui avaient l'habitude de concevoir des SGBDR, NoSql ressemble à des anti-modèles de SQL et cela a plus de sens quand on le considère dans le cadre d'un DDD.
Selon l'utilisation des adresses, vous pouvez le définir en tant qu'objet de valeur dans votre modèle / entité d'historique de location.
Voici quelques références qui pourraient éclaircir votre réflexion sur le design avec NoSQL:
la source
TL; DR
La normalisation dans le SGBDR vous permet d’exploiter les atouts du paradigme relationnel.
La dénormalisation dans NoSQL vous permet de tirer parti des atouts du paradigme NoSQL.
Longue réponse
Les SGBDR sont intéressants car ils vous permettent de modéliser des entités structurées uniques (modifiables ou non) et leurs relations les unes avec les autres. Cela signifie qu'il est très facile de travailler au niveau de l'entité, de mettre à jour ses propriétés, d'en insérer une autre, d'en supprimer une, etc. Le SGBDR vous donne des outils pour faciliter tout cela. Il se joindra à vous, il gérera les modifications atomiques entre entités, etc.
Les bases de données NoSQL sont excellentes car elles vous permettent de modéliser des agrégats semi / non structurés et des entités dynamiques. Cela signifie qu'il est très facile de modéliser des entités en constante évolution, des entités qui ne partagent pas toutes les mêmes attributs et des agrégats hiérarchiques.
Pour modéliser NoSql, vous devez penser en termes de hiérarchie et d’agrégats au lieu d’entités et de relations. Donc, vous n'avez pas de personne, d'adresses de location et de relations entre eux. Vous avez des enregistrements de location qui regroupent pour chaque personne les adresses de location qu’elle a eues.
Vous devez demander quelles données devront être modifiées ensemble. Quelles données regroupent logiquement les autres données. Dans votre cas, une personne semble être un bon agrégat. Quel est le point d'entrée logique vers le reste des données?
NoSQL, disons, stocke une chose qui a d'autres choses qui ont des choses qui leur sont propres. Rends-moi toute la hiérarchie des choses. Permettez-moi de le changer à ma guise, remplacez maintenant toute la hiérarchie des choses par celle que j'ai modifiée C'est à peu près tout ce que cela vous donne. Pourquoi est-ce utile? Si ce que vous avez est une hiérarchie de choses avec lesquelles vous interagissez toujours dans son ensemble. Ou si vous avez besoin d'une mise à l'échelle massive.
Tout ce que le SGBDR vous donne, vous devrez l'implémenter manuellement dans le code et dans votre schéma. Vous devrez vous connecter à un code si vous avez besoin d'un agrégat d'agrégats. Vous devrez analyser si vous n'avez besoin que d'une partie d'un agrégat. Vous devrez vérifier l'unicité vous-même si vous ne voulez pas dupliquer les choses. Vous devrez implémenter votre propre logique transactionnelle lorsque vous travaillez sur des agrégats, etc.
Donc, avoir une grande table avec tout ce dont vous avez besoin est la voie à suivre dans NoSql. Depuis l'atomicité est garantie à ce niveau seulement, et la performance aussi. Comprendre vos relations tôt est important. C'est ce que la dénormalisation est.
Dans les SGBDR, la dénormalisation paralyse votre base de données par une base NoSQL. Donc, normalement, vous voulez le contraire, c'est-à-dire la normalisation. Sinon, vous devriez plutôt utiliser une base de données NoSQL. Sauf si vous avez besoin d'un peu des deux.
la source