Comment puis-je argumenter de manière convaincante contre la duplication de colonnes de base de données?
J'ai commencé à travailler dans une nouvelle organisation et l'un des modèles que j'ai vu dans la base de données est la duplication des champs pour faciliter l'écriture des requêtes pour les analystes commerciaux. Nous utilisons Django et son ORM.
Dans un cas, nous gardons un objet MedicalRecordNumber avec une chaîne unique identifiant un patient dans un certain contexte. Nous avons Enregistrement des objets qui suivent les patients et ont associé MedicalRecordNumbers , mais plutôt que d'utiliser une relation de clé étrangère, ils dupliquent la chaîne afin d'éviter d'écrire une jointure (pas pour des raisons de performances). Ce modèle est courant dans toute la base de données.
Pour moi, l'importance d'un modèle de données propre est juste pour que je puisse bien y penser. La complexité inutile est un gaspillage de mon temps de traitement cognitif limité. C'est un problème systématique. Ne pas être à l'aise pour écrire des jointures est un problème de compétences rectifiable. Je ne veux pas nécessairement préconiser un retour en arrière et un changement de schéma, mais j'aimerais pouvoir articuler de manière convaincante les problèmes de ce type de duplication.
Votre base de données opérationnelle doit être hautement normalisée, pour réduire anomalies .
Votre base de données analytique (entrepôt) doit être hautement dénormalisée pour faciliter l'analyse.
Si vous ne disposez pas d'une base de données analytique distincte, vous devez créer des vues [matérialisées] hautement dénormalisées.
Si vous dites à vos analystes/directeurs commerciaux principaux de faire beaucoup de jointures pour une analyse simple, eh bien, vous pourriez être viré.
Agile Data Warehouse Design est un bon livre
Voir mes conseils rapides sur les entrepôts de données n --- ici
Je comprends, pourquoi quelqu'un veut éviter d'écrire une jointure pour chaque sélectionner.
Mais vous pouvez créer ne fois une vue avec la jointure et l'utiliser à la place de votre table non normalisée.
Ainsi, vous combinez l'avantage de la normalisation avec la commodité d'une sélection facile.
Les réponses qui ont déjà été majorées couvrent à peu près le "comment éviter la duplication" (en utilisant des vues) mais pas le pourquoi. Ils montrent essentiellement que la duplication des colonnes n'est pas la bonne solution au problème de faciliter l'écriture des requêtes. Mais la question "pourquoi ne pas dupliquer une colonne au hasard juste pour le plaisir?" encore debout.
La réponse est "à cause de la loi de Murphy". La loi de Murphy stipule que:
Si quelque chose peut mal tourner, ce sera le cas.
Dans ce cas, le contenu de chaque champ de ligne d'une colonne dupliquée est censé être identique au contenu de chaque champ de ligne correspondant de la colonne d'origine. Ce qui peut mal tourner, c'est que le contenu de certains champs de ligne peut différer des originaux, ce qui fait des ravages. Vous pourriez penser que vous avez pris toutes les précautions imaginables pour vous assurer qu'elles ne diffèrent pas, mais la loi de Murphy stipule que puisque elles peuvent différer, ils seront différents. Et des ravages s'ensuivront .
Comme exemple de la façon dont cela peut se produire, considérez simplement le fait que les colonnes dupliquées ne sont pas remplies par magie; quelqu'un doit réellement écrire du code qui y stocke des valeurs chaque fois que des lignes sont créées dans la table d'origine, et quelqu'un doit écrire du code qui les met à jour chaque fois que les originaux sont modifiés. En mettant de côté le fait que cela ajoute une charge excessive au code qui entre les données dans la base de données (et qui est, par définition, beaucoup plus crucial que tout code qui interroge simplement la base de données), quelqu'un, quelque part, dans certaines circonstances, pourrait oublier pour effectuer cette duplication. Ensuite, les valeurs différeront. Ou ils peuvent se rappeler d'effectuer la duplication, mais pas dans le cadre d'une transaction, de sorte que celle-ci peut, sous certaines conditions de faute rares, être omise. Mais je n'avais pas vraiment besoin de perdre mon temps à écrire ces exemples, et vous n'aviez pas vraiment besoin de perdre votre temps à les lire: la beauté de la loi de Murphy est qu'elle nous évite d'avoir à trouver des exemples de la façon dont quelque chose peut mal tourner au cas par cas: si cela peut mal tourner, cela se produira.
Penser à cela en termes de compromis plutôt que de bon/mauvais sera plus productif. Ils troquent les avantages de la normalisation (en particulier la cohérence) contre des avantages en termes d'utilisation des requêtes.
À un extrême, la base de données deviendrait inutile si les données devenaient gravement incohérentes. À l'autre extrême, la base de données serait inutile si elle est trop difficile pour les personnes qui ont besoin de l'interroger quotidiennement pour obtenir des résultats sur lesquels elles peuvent compter.
Que pouvez-vous faire pour réduire les risques et les coûts?
- Créez un outil de vérification de cohérence et exécutez-le régulièrement.
- Acheminez l'accès en écriture via un logiciel qui met à jour les données répliquées de manière cohérente.
- Ajoutez des vues ou créez des outils de requête qui effectuent les jointures automatiquement afin que les hommes d'affaires puissent penser en termes d'informations plutôt qu'en termes de bases de données DB.
Je pense que l'argument le plus fort en faveur de la normalisation des données pour les analystes commerciaux est qu'elle favorise l'intégrité des données. Si vos données clés sont stockées dans un seul endroit (une colonne, dans une table), il est beaucoup moins probable que les données soient corrompues par des mises à jour incorrectes. Je pense qu'ils se soucieraient probablement de l'importance de l'intégrité des données, donc cela pourrait être un bon moyen de les convaincre de mettre à jour leurs façons d'interagir avec la base de données.
Une méthode d'interrogation légèrement plus difficile sera probablement préférable à une corruption potentielle des données.
Pour ajouter à ce que les autres gars ont suggéré ci-dessus. Il s'agit d'un problème de gouvernance des données. Vous devez travailler avec les parties prenantes concernées: les architectes de données et les gestionnaires de données pour développer des principes, des politiques et des conventions de dénomination des données.
Soyez patient et travaillez méthodiquement. Le changement ne se fera pas du jour au lendemain.
Quitter.
Honnêtement, vous pouvez passer des mois à discuter de la normalisation, de la cohérence et à lutter contre les bugs fous causés par la pure paresse, puis à quitter.
Ou vous pouvez simplement gagner du temps, de la frustration et arrêter de fumer maintenant.
Les bons programmeurs sont des gens très paresseux. Ils comprennent les besoins des clients et de la gestion. Mais surtout, ils comprennent que bien résoudre les problèmes, utiliser des solutions bien conçues et bien implémentées les sauve personnellement [~ # ~] énorme [~ # ~] quantités de travail, d'efforts, et surtout d'agonie et de stress.
Il serait donc préférable de travailler dans un endroit qui comprend et valorise une bonne ingénierie.
Bonne chance.
Après coup: peut-être qu'ils ont besoin de BI/OLAP ... http://en.wikipedia.org/wiki/Online_analytical_processing