J'ai une quantité décente de données dans une base de données. J'ai des tables bien formées et de bonnes relations entre elles avec une certaine redondance dans mes données. Mais jusqu'où dois-je aller avec la normalisation? Y a-t-il des inconvénients de performances à trop de normalisation?
Réponses:
Vous devriez aller aussi loin que vous le devriez et pas plus loin. Bien sûr. ~ Le problème peut être que c'est un peu un art, et c'est pourquoi ce n'est pas une pure science.
Notre produit principal est un système d'analyse et de reporting, et donc à cet égard, nous avons pas mal de dossiers détaillés. Nous l'avons initialement conçu avec beaucoup de jointures sur un ID commun pour certains des enregistrements enfants, mais nous avons constaté que si nous dénormalisions quelques champs, nous pouvions supprimer beaucoup de jointures et nous pouvions éliminer beaucoup de problèmes de performance.
Mais nous savions seulement que parce que nous 1) avons créé une conception "normalisée", 2) avons commencé à l'utiliser, 3) profilé les performances réelles après des centaines de millions de lignes sur des dizaines de tables.
L'histoire finale est que jusqu'à ce que nous établissions le profil, nous ne pouvions pas savoir avec certitude ce qui allait fonctionner pour nous. Nous avons aimé l'idée de normaliser afin de pouvoir mettre à jour plus facilement, mais au final, les performances réelles ont été le facteur décisif. Voilà mon conseil pour vous: profil, profil, profil.
in ('forgiven','pardoned');): p
La normalisation n'est un objectif que lorsqu'elle prend suffisamment en charge votre modèle de données pour le garantir. Il est censé être un guide pour permettre la croissance, la gestion et la maintenabilité. N'oubliez pas que le livre sur la normalisation, ni son rédacteur vont construire ou maintenir votre base de données ou son application.
Une bonne lecture au sujet de "trop de normalisation" est ici.
Et, oui, il peut y avoir des impacts sur les performances de trop de normalisation. Ce serait dans une traversée de table plus profonde pour ramasser des choses comme les tables d'indicateur d'état lorsqu'elles ont été retirées dans une table distincte. Certains diront que cela est généralement annulé dans la vitesse de mise à jour (changement du texte d'état de "Bon" à "BON" ou quelque chose de similaire) ou dans la maintenabilité.
Je recommande de lire l'annexe suivante que l'on trouve dans quelques-uns des livres les plus récents de Chris Date :
Deux acclamations pour la normalisation
La normalisation est loin d'être une panacée, comme on peut facilement le voir en considérant quels sont ses objectifs et dans quelle mesure elle s'y compare ...
Je dois préciser que je ne veux pas que mes commentaires dans cette section soient considérés comme une sorte d'attaque. Je crois fermement que rien de moins qu'un design entièrement normalisé est fortement contre-indiqué ...
Je pense qu'il est tout aussi important de regarder les dénormalisations ajoutées explicites, soit les valeurs agrégées ajoutées, soit certains champs d'une table principale copiés dans une copie détaillée.
L'argument étant principalement un argument de performance.
Si vous le faites, assurez-vous que ces champs sont mis à jour par des déclencheurs et que c'est à la base de données de les garder cohérents.
Je suis totalement d'accord avec @jcolebrand. Lorsque vous concevez un modèle pour votre application, vous devez normaliser tout ce que vous pouvez. Mais ensuite, vous devez profiler les requêtes construites sur votre modèle, en particulier celles exécutées fréquemment.
Ma propre expérience: les attributs qui ont pris deux jointures (c'est-à-dire trois tables jointes) seront principalement un porc de performance. Et pour aggraver les choses, il est utilisé dans les transactions en ligne. Je dénormalise l'attribut, il suffit donc d'une jointure et j'ai demandé au programmeur d'ajuster son application pour la requête et de mettre à jour l'attribut. Maintenant ça marche beaucoup mieux ...
En d'autres termes, vous devez équilibrer la normalisation avec les performances.