Lorsque vous prenez une base de données d'une forme relativement normalisée et de le normaliser, ce que, le cas échéant, changements dans l'utilisation des ressources pourrait s'attendre?
Par exemple, la normalisation signifie souvent que plus de tables sont créées à partir de moins, ce qui signifie que la base de données a maintenant un nombre plus élevé de tables, mais beaucoup d'entre eux sont assez petits, ce qui permet aux habitudes souvent utilisées de mieux s'intégrer à la mémoire.
Le nombre élevé de tables signifie également que davantage de jointures sont nécessaires (potentiellement) pour obtenir aux données qui ont été résumées. On peut donc s'attendre à une sorte d'impact du plus grand nombre de jointures dont le système doit faire.
Ainsi, quel impact sur l'utilisation des ressources (c'est-à-dire ce qui changera) normaliser une base de données non normalisée?
EDIT:
Pour ajouter un peu de contexte, j'ai une base de données existante (c.-à-d. Héritage) avec plus de 300 tables horribles. Environ 1/2 des données est du texte et l'autre moitié est soit des champs de caractères, soit des entiers. Il n'y a aucune contrainte d'aucune sorte. La raison pour laquelle je demande est principalement d'obtenir plus d'informations pour convaincre d'autres que les choses doivent changer et qu'il n'y aura pas de diminution de la performance ou de la maintenabilité. Malheureusement, ceux que je dois convaincre, connaissez simplement les avantages de la performance d'une base de données dés-normalisée pour éviter toute normalisation autant que possible.
8 Réponses :
Pour une chose, vous finirez par avoir à faire des calculs de résultatsset. Par exemple, si vous avez un blog code>, avec un numéro de POST code> S, vous pouvez le faire: select PostCount from Blog where ID = @BlogID
Il y a une réponse très simple à votre question: cela dépend.
Premièrement, je vais réaffirmer votre question comme «quel est l'avantage de la dénormalisation», car la normalisation est la chose qui devrait être faite par défaut (à la suite d'un modèle logique pur), puis de dénormalisation peut être appliqué pour des tables très spécifiques où la performance est critique. Le principal problème de la dénormalisation est qu'il peut compliquer la gestion de l'intégrité des données, mais les avantages dans certains cas l'emportent sur les risques.
Mes conseils pour la dénormalisation: Ne le faites que lorsqu'il fait vraiment mal et que vous avez obtenu tous les scénarios couverts lorsqu'il s'agit de maintenir l'intégrité des données après tout insertion, mises à jour ou supprimées.
Cela ressemble à des conseils que j'ai entendus et ont tendance à être d'accord avec, maintenant que j'ai une certaine expérience sous ma courroie - "Normaliser jusqu'à ce qu'il blesse la performance, et plus rien."
Cela ne peut pas vraiment être répondu de manière générale, car l'impact varie fortement en fonction des spécificités de la base de données en question et des applications l'utilise.
Vous avez donc essentiellement indiqué les attentes générales concernant l'impact:
Donc, la seule réponse réelle est l'habituelle: cela dépend;)
Remarque: cela suppose que nous parlons de dénormalisation prudente et intentionnelle . Si vous vous référez à ', jetez des tables ensemble car les données se présentent « approche de manière à communiquer avec des développeurs inexpérimentés, je risquerais la déclaration que la normalisation réduira les besoins en ressources à tous les niveaux;) < / p>
EDIT: Concernant le contexte spécifique ajouté par CDESZAQ, je dirais que "bonne chance de faire ton point";)
Ovment, avec plus de 300 tables et aucune contrainte (!), la réponse à votre question est définitivement "normalisée réduira les besoins en ressources à tous les niveaux" (et probablement très sensiblement), refactorise un tel désordre Donc, même si la normalisation réduirait sensiblement les besoins en ressources à long terme, il est pourrait ne pas valoir la peine, en fonction des circonstances. Les principales questions sont sur la portée à long terme - Quelle est la qualité de cette base de données, combien de temps sera-t-elle utilisée, y aura-t-il plus d'applications l'utiliser à l'avenir, est l'effort de maintenance actuel constant ou augmentant, etc. ...
Ne pas ignorer que c'est un Système d'exécution - même si c'est moche et horrible, selon votre description ce n'est pas (encore) cassé ; -) < / p>
J'ai trouvé que la normalisation, dans certains cas, améliorera performance.
Petites tables en lecture plus rapidement. Une base de données gravement dénormalisée aura souvent (a) des lignes plus longues et (b) plus de lignes qu'une conception normalisée.
lire moins de rangées plus courtes signifie moins d'E / S physique.
Pour souligner certains points faits par des affiches antérieures: est-ce que votre schéma actuel est-il vraiment désormalisé? La manière appropriée (IMHO) de concevoir une base de données est de:
(Il peut y avoir d'autres raisons de se désoloraliser, mais les seuls que je puisse penser de hors mains sont politiques - doivent correspondre au code existant, les développeurs / gestionnaires ne l'aiment pas, etc.)
Mon point est, si vous n'avez jamais complètement normalisé, vous n'avez pas de base de données dénormalisée, vous avez un non formé un. Et je pense que vous pouvez penser à plus de descriptif si des termes moins polis pour ces bases de données.
Je peux en effet penser à d'autres noms pour cette base de données, et oui, c'est une base de données non soul) , comme vous le dites. Merci pour la clarification.
Les schémas normalisés ont tendance à mieux performer pour insertion / mise à jour / Supprimer car il n'y a pas de "anomalies de mise à jour" et les modifications réelles à apporter sont plus localisées.
Sélectionneurs sont mélangés. La dénormalisation matérialisait éruptueusement une jointure. Il ne fait aucun doute que matérialiser une jointure contribue parfois, cependant, la matérialisation est souvent très pessimiste (probablement plus souvent que non), alors ne supposez pas que la dénormalisation vous aidera. En outre, des schémas normalisés sont généralement plus petits et peuvent donc nécessiter moins d'E / S. Une jointure n'est pas nécessairement chère, alors ne supposez pas automatiquement que ce sera.
"Normalisation" s'applique uniquement et exclusivement à la conception logique d'une base de données.
La conception logique d'une base de données et la conception physique d'une base de données sont deux complètement distinctes choses. La théorie de la base de données a toujours destiné aux choses comme ça. Le fait que les développeurs qui négligent / ignorent cette distinction (à l'échelle de l'ignorance ou de l'insouciance ou de la paresse ou de la paresse ou de toute autre raison dit "raisonnable" "raison") sont la grande majorité, ne les rend pas corrects.
A la conception logique peut être dit être normalisée ou non, mais une conception logique ne porte intrinsèquement aucune "caractéristique de performance" de ce que ce soit. Juste comme 'c: = c + 1;' ne porte intrinsèquement aucune caractéristique de performance.
a la conception physique détermine "Caractéristiques de performance", mais à nouveau, une conception physique n'a tout simplement pas la qualité d'être "normalisée ou non".
Cette perception erronée de la "performance de mauvaise qualité" n'est vraiment rien d'autre que la preuve concrète que tous les moteurs de la SGBD qui existent aujourd'hui ne font que manquer sérieusement des options de conception physique.
Je voulais élaborer sur Henrik Opel's # 3 Bullet Point . Coûts de développement pourrait montez, mais ils n'ont pas à. En fait, la normalisation d'une base de données devrait simplifier ou permettre l'utilisation d'outils tels que les orateurs, les générateurs de code, les écrivains de rapports, etc. Ces outils peuvent réduire considérablement le temps passé sur la couche d'accès aux données de vos applications et déplacer le développement pour ajouter des affaires. valeur.
Vous pouvez trouver une bonne discussion sur Stackoverflow ici < / a> sur l'aspect développement des bases de données normalisées. Il y avait beaucoup de bonnes réponses, de commentaires et de choses à penser.
L'espace extrêmement problématique dépend, en fonction du type de données que vous pouviez voir que l'espace de stockage passe vers le bas ou le chemin.
Il y a un très bon message à propos de ce sujet dans Stackoverflow.com/Questtions/173726/...
@Gmonc - Oui, c'est un excellent article, mais je veux savoir comment l'utilisation des ressources change d'une version non formée à une version normalisée de la même base de données.
Vous devriez consulter le livre de Scott Ambler, refactoring Base de données.