Est-il judicieux de normaliser l'inclusion d'une date de création et d'un champ de date de dernière mise à jour sur toutes les tables de base de données?
Mon patron tente actuellement d'appliquer certaines normes de développement à notre équipe, nous avons donc eu une réunion hier pour discuter des normes qui se déroulaient généralement bien jusqu'à ce qu'elle mentionne:
- Toutes les tables de base de données auront une colonne CreatedDate et LastUpdatedDate, mise à jour par des déclencheurs.
À ce stade, notre équipe a souffert d'un schisme d'opinion; la moitié d'entre nous pense que faire cela sur toutes les tables est une grande quantité de travail avec peu d'avantages (nous travaillons sur des projets à budget fixe donc tout coût provient des bénéfices de notre entreprise); la seconde moitié pense que cela aidera à soutenir les projets.
Je suis fermement dans l'ancien camp. Bien que j'apprécie que certains cas extérieurs entraîneraient une amélioration de la prise en charge des colonnes supplémentaires, à mon avis, la quantité de travail qui serait nécessaire pour ajouter les colonnes en premier lieu, ainsi que la maintenance, nous obligerait à consacrer moins de temps à plus des choses importantes comme les tests unitaires ou de charge. De plus, je suis assez sûr que ces colonnes supplémentaires rendraient plus difficile l'utilisation d'un ORM - en gardant à l'esprit que nous utilisons principalement C # et Oracle, qui n'est pas très content d'ORM au départ.
Donc, ma question est double:
- Suis-je dans le bon camp? Je ne prétends pas avoir des compétences de base de données de renommée mondiale, donc cela pourrait être un ajout trivialement facile sans effets secondaires indésirables.
- Comment feriez-vous face à une situation où une réunion sur les normes se transforme en un match nul? Comment puis-je vraiment vendre que cette norme ne va pas nous aider à long terme?
Il s'agit d'une pratique assez courante, même si je ne dirais pas que la prise en charge est le principal avantage. Le véritable avantage de cette approche est de conserver une piste d'audit. Il est également courant d'avoir une colonne supplémentaire contenant le nom d'utilisateur de l'utilisateur qui a effectué la dernière mise à jour.
Si vous avez affaire à des données financières ou sensibles, je suis sûr que vous avez entendu parler de choses comme PCI & SOX conformité. Une piste d'audit complète est essentielle pour répondre à ces spécifications.
Avertissement: Il existe cependant de bien meilleures façons de réaliser une piste d'audit de base de données> https://stackoverflow.com/questions/1051449/ideas-on-database-design-for-capturing-audit-trails
Le premier argument n'est pas valide, car l'ajout de quelques champs d'horodatage maintenus par la base de données à une série de tables n'est pas un travail difficile. C'est en fait le genre de tâche engourdissante que l'on donnerait à un junior ou à un stagiaire, et ils pourraient facilement le faire en un seul sprint de deux semaines avec du temps à perdre.
Il peut même être nécessaire ou non de mapper ces champs dans votre ORM, simplement parce que vous ne voulez pas que les utilisateurs d'application modifient ces champs et parce qu'ils sont utiles pour la maintenance et le débogage et ont rarement une utilisation dans la logique métier. J'ai travaillé dans des magasins qui l'ont fait dans les deux sens et je n'ai franchement pas beaucoup d'opinion sur cette façon.
Les avantages, même s'ils sont exagérés, dépassent de loin tous les coûts humains liés à la mise en œuvre d'une telle fonctionnalité au niveau de la base de données, et certainement moins que la puissance cérébrale collective des grands esprits techniques du projet détournant la réunion et la combattant dans un match épique. Lorsque vous comptez l'impact de quelques réunions d'une heure sur la durée de vie d'un projet, vous ne serez probablement pas surpris qu'elles soient coûteuses. Imaginez le salaire horaire collectif et les avantages sociaux de toutes ces personnes réunies et cela devrait vous donner une idée.
... plus un homme fait de déclarations définitives, plus il a de chances de se tromper définitivement ... - Tyler Durden
cela s'applique aux "standards" généraux, alors que sur certaines tables, cela pourrait être une énorme victoire, sur chaque table, il y aurait très probablement du bruit inutile et plus de code à maintenir ou oublier de maintenir.
il y a un équilibre à trouver ici, c'est ce que vous devez pousser auprès des décideurs.
Je suis de tout coeur. Presque chaque table dans chaque base de données doit avoir au moins 2 champs: date de création et date de mise à jour. Il existe de nombreuses raisons pour lesquelles vous devez mettre une date de création et une date de mise à jour. Pour des raisons évidentes que les personnes précédentes ont déclaré… ce qui est de l'audit.
Je conçois des systèmes et des bases de données depuis 25 ans et j'ai travaillé pour des centaines de clients. Il n'y a pas un seul client qui n'en a PAS eu besoin.
Il existe 2 méthodes de base pour ce faire:
1 - La première pratique consiste à laisser la base de données faire le travail et à l'intégrer directement dans la conception de la table. C'est le strict minimum, je recommanderais.
2 - L'autre pratique, que je préfère .... est d'utiliser un outil de réplication pour gérer cela. Il y a peu de frais généraux et aucun coût pour les équipes DEV. Cependant, les outils sont chers. Un avantage supplémentaire est que le processus de suppression peut être audité beaucoup plus facilement avec ce type d'outil. Sans outil de réplication, vous auriez besoin de créer une table d'audit et de déclencher des déclencheurs pour les suppressions - ce n'est pas une bonne pratique à mon avis.
Un autre avantage de ces champs est l'entrepôt de données et ODS qui sont TOUJOURS construits pour tout système OLTP. Vous ne pouvez pas extraire efficacement des données incrémentielles sans lui. Sinon, vous risquez d'avoir à recharger la base de données entière tous les jours .
Il y a un nombre énorme d'autres raisons commerciales pour mettre ces 2 dates, que je ne vais pas approfondir ici. Faites vos devoirs et je suis sûr que 3-6-12-48 mois plus tard, vous serez très heureux de mettre ces 2 champs simples.
J'ai mis en œuvre et recommande généralement les deux solutions lorsque cela est possible.
Nous avons la date de création et les colonnes créées dans notre base de données et elles nous ont énormément aidés à dépister les problèmes de données. Si nous devons revenir en arrière, cela nous aide à trouver les enregistrements corrects dans les tables d'audit complètes (car nous savons où chercher dans une très grande table). Elle doit également ajouter une colonne créée par et modifiée par. Cela aide vraiment vraiment de savoir qui a mis les données, surtout si vous ne disposez pas d'un audit complet.
Je ne peux penser à aucune application d'entreprise qui ne nécessite pas d'audit d'une forme ou d'une autre. Apparemment, votre patron pense qu'il n'a besoin que d'un audit relativement léger. Personnellement, je préfère un audit complet sur chaque base de données contenant des données dont votre entreprise dépend (il est beaucoup plus facile de revenir sur ces 2000 mauvais enregistrements des tables d'audit que de restaurer des sauvegardes) et l'exigerais s'il y avait des informations financières du tout comme je ont vu ce genre de choses aider à attraper des gens en train de frauder. Tous les audits doivent être au niveau de la base de données.
Comment ces données peuvent-elles aider? Eh bien, tout d'abord, il réduit le moment de rechercher les anciennes données (dans une révision) et il peut vous aider à voir quelle version de votre programme était active au moment où les données ont été entrées. Donc, si vous savez que vous avez résolu ce problème dans la version 2.3 qui a été mise en ligne le 6 juillet 2011 et que vous avez ensuite trouvé le même problème avec un enregistrement inséré le 7 août, alors peut-être que votre solution n'était pas bonne. Si vous devez revenir aux anciennes données, il vous indiquera dans quelle version des sauvegardes vous pouvez trouver les anciennes données si vous ne disposez pas d'un audit complet.
Les développeurs semblent rarement penser que les données doivent être conservées dans le temps et que les mauvaises données doivent être corrigées par quelqu'un. Avoir des choses comme ça peut être très précieux pour ceux d'entre nous qui doivent faire de telles choses. Votre patron a raison, même si je ne pense pas qu'elle soit allée assez loin dans l'audit. Il suffit d'un problème vraiment grave et facile à résoudre pour justifier le très petit temps qu'il faudra pour ajouter ces colonnes et déclencheurs.
La charge de travail est théorique car cela peut être scripté et appliqué à chaque base de données que vous créerez. Ajoutez les colonnes à toutes les tables avec les déclencheurs. Vous devez juste vous rappeler de l'exécuter avec votre build.
En ce qui concerne ce que le client veut, vous pouvez lui faire payer pour l'intégrer dans votre application comme bon lui semble. Beaucoup aiment voir des informations supplémentaires sur un enregistrement comme qui l'a créé/modifié en dernier et quand. Pas besoin d'envoyer à tout le monde un e-mail pour le savoir ou pour lui mentir. Vous ne voulez pas avoir à interroger un journal chaque fois que quelqu'un regarde un enregistrement.
Le mettre dans la base de données et l'avoir là juste au cas où ce n'est pas si difficile et peut vous permettre de facturer des fonctionnalités supplémentaires qui utilisent les champs ou simplement de vous donner des commentaires sur la quantité de clients qui utilisent le système.
Ce serait assez trivial à mettre en œuvre (peut-être 1 à 3 jours au total), donc à mon avis, sa valeur ajoutée à votre application au cours de sa durée de vie.
Tout d'abord, une instruction alter table serait nécessaire pour ajouter les colonnes, la table alter serait la même (sauf pour le nom de la table), donc vous pourriez écrire un script pour coder générer l'instruction alter SQL pour toutes les tables nécessaires . Vous devez autoriser les valeurs NULL à prendre en compte les données existantes et vérifier l'existence des colonnes afin qu'elles soient réexécutables.
Deuxièmement, pour les colonnes, l'utilisation de valeurs par défaut, comme GetUTCDate () (SQL Server, Oracle peut-être différent) résout tous les ajouts de codage lors de l'insertion, de sorte que la base de code n'a pas à changer pour aucune des instructions inserts car les valeurs par défaut seront utilisé.
Les mises à jour des données (passer à la dernière modification) pourraient être résolues avec un déclencheur de mise à jour. Encore une fois, ce déclencheur serait presque le même pour toutes les tables, donc ce code de déclenchement (SQL) pourrait également être généré pour toutes les tables existantes.
Il y aurait potentiellement beaucoup de code de script SQL (selon le nombre de tables), mais c'est un modèle qui est répétable, vous pouvez donc le générer en codant en regardant un schéma de base de données existant.