Est-il judicieux de normaliser l'inclusion d'une date créée et du 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 nous sommes donc réunis hier pour discuter des normes, qui fonctionnaient généralement bien jusqu'à ce qu'elle nous parle:

• Toutes les tables de base de données auront une colonne CreatedDate et LastUpdatedDate, mises à jour par les déclencheurs.

À ce stade, notre équipe a subi un schisme d'opinion; la moitié d'entre nous pensent que cela représente beaucoup de travail avec peu d'avantages sur toutes les tables (nous travaillons sur des projets à budget fixe, de sorte que 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 amènent les colonnes supplémentaires à améliorer la prise en charge, à mon avis, la quantité de travail nécessaire pour ajouter les colonnes en premier lieu, ainsi que la maintenance, nous feraient perdre moins de temps à plus de temps. des choses importantes comme les tests unitaires ou en charge. De plus, je suis à peu près sûr que ces colonnes supplémentaires rendraient l'utilisation d'un ORM plus délicate, sachant que nous utilisons principalement C # et Oracle, ce qui n'est pas très agréable 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, alors cela pourrait être un ajout trivialement facile sans effets secondaires indésirables.
• Comment géreriez-vous une situation dans laquelle une réunion sur les normes se transforme en une partie de conflit? Comment puis-je vraiment vendre que cette norme ne va pas nous aider à long terme?

C'est une pratique assez courante, bien que 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 de vérification. 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 traitez avec n'importe quel type de données financières ou sensibles, je suis sûr que vous avez entendu parler de choses comme la conformité PCI & SOX . Avoir une piste d'audit complète est essentiel pour répondre à ces spécifications.

Clause de non-responsabilité: Il existe cependant de bien meilleurs moyens de créer 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 conservés à une base de données à une série de tables n'est pas un travail difficile. C’est en fait le genre de tâche angoissante que l’on confierait à un stagiaire ou à un stagiaire. Ils pourraient facilement le faire en un seul sprint de deux semaines, avec suffisamment de temps.

Il peut être nécessaire ou non de mapper ces champs dans votre ORM, tout simplement parce que vous ne souhaitez pas que les utilisateurs de l'application modifient ces champs, car ils sont utiles pour la maintenance et le débogage et sont rarement utilisés dans la logique métier. J'ai travaillé dans des magasins qui fonctionnaient dans les deux sens et, franchement, je n'ai pas vraiment d'opinion là-dessus.

Les avantages, même exagérés, dépassent de loin les coûts humains liés à la mise en œuvre de telles fonctionnalités au niveau de la base de données, et probablement moins que l’intelligence collective des projets. Lorsque vous calculez 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 chères. Imaginez le salaire horaire et les avantages collectifs 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 risque de se tromper définitivement ... - tyler durden

ceci s'applique aux "normes" générales, alors que sur certaines tables, cela pourrait être une victoire énorme, sur chaque table, ce serait probablement du bruit inutile et plus de code à maintenir ou à oublier à entretenir.

il y a un équilibre à trouver ici, c'est ce que vous devriez pousser aux décideurs.

Je suis tout à fait d'accord. Presque toutes les tables de chaque base de données doivent comporter au moins deux champs: la date de création et la date de mise à jour . Il existe de nombreuses raisons pour lesquelles vous devez indiquer une date de création et une date de mise à jour. Pour des raisons évidentes, ce que des personnes précédentes ont déclaré… qui est 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 besoin.

Il y a 2 façons de faire cela:

1 - La première pratique consiste à laisser la base de données effectuer le travail et l'insérer directement dans la conception de la table. Quel est le strict minimum, je recommanderais.

2 - L’autre pratique, que je préfère .... utilise 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 de développement. 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 un outil de réplication, vous auriez besoin de créer une table d'audit et d'activer les déclencheurs pour les suppressions - ce n'est pas une bonne pratique à mon avis.

Un autre avantage à avoir ces champs est l'entrepôt de données et l'ODS qui est TOUJOURS construit pour tout système OLTP. Vous ne pouvez pas extraire efficacement les données incrémentielles sans cela. Sinon, vous risquez de devoir recharger tous les jours la totalité de la base de données.

Il y a énormément d'autres raisons commerciales pour indiquer ces deux dates, que je ne vais pas approfondir ici. Faites vos devoirs et je suis sûr que dans 3-6-12-48 mois, vous serez très heureux de mettre ces deux champs simples.

J'ai implémenté et recommande généralement les deux solutions dans la mesure du 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ées à repérer les problèmes de données. Si nous devons revenir, 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 devrait aussi ajouter un créé par et modifié par des colonnes. Il est vraiment très utile de savoir qui a mis les données, surtout si vous n’avez pas l’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 modéré. Personnellement, je suis favorable à un audit complet de chaque base de données contenant des données dont dépend votre entreprise (il est beaucoup plus facile de récupérer ces 2 000 mauvais enregistrements à partir de tables d'audit que de restaurer des sauvegardes) et l'exigerais si des informations financières étaient disponibles. ont vu ce genre de chose aider à attraper les fraudeurs. Tous les audits doivent être au niveau de la base de données.

Comment ces données peuvent-elles aider? Tout d’abord, il faut savoir quand chercher les anciennes données (dans une révision) et cela 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 corrigé ce problème dans la version 2.3, qui a été mise en ligne le 6 juillet 2011 et a ensuite rencontré 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 restaurer d'anciennes données, il vous indiquera la version des sauvegardes dans laquelle vous pourrez retrouver 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 au fil du temps et que les mauvaises données doivent être réparées par quelqu'un. Avoir de telles choses peut être très précieux pour ceux d’entre nous qui devons 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 très grave, facile à résoudre, pour justifier le temps très court nécessaire à l'ajout de ces colonnes et de ces déclencheurs.

La charge de travail est inutile car elle peut être scriptée et appliquée à toutes les bases de données que vous créerez un jour. 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 les besoins du client, vous pouvez les faire payer pour les intégrer à votre application comme bon leur semble. Beaucoup aiment voir des informations supplémentaires sur un enregistrement, comme par exemple qui l'a créé / modifié et quand. Pas besoin d'envoyer un e-mail à tout le monde pour le savoir ou se faire mentir. Vous ne voulez pas avoir à interroger un journal chaque fois que quelqu'un consulte un enregistrement.

Le placer dans la base de données et le conserver juste au cas où ce ne serait pas si difficile et pourrait vous permettre de facturer des fonctionnalités supplémentaires utilisant les champs ou simplement de vous donner une idée de l’utilisation des systèmes par les clients.

Ce serait assez simple à mettre en œuvre (peut-être 1 à 3 jours au total), donc, à mon avis, quelle valeur cela va-t-il ajouter à 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 étant identique (à l'exception du nom de la table), vous pouvez donc écrire un script pour générer dans le code la déclaration alter SQL pour toutes les tables nécessaires. . Il faut permettre aux valeurs NULL de prendre en compte les données existantes et de vérifier l’existence des colonnes afin qu’elles puissent être réexécutées.

Deuxièmement, pour les colonnes, l'utilisation de valeurs par défaut, telles que GetUTCDate () (SQL Server, Oracle peut être différent), résout tous les ajouts de code lors de l'insertion, de sorte que la base de code ne doit pas être modifiée pour les instructions insérées, car les valeurs par défaut seront utilisé.

Les mises à jour des données (modification de 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, de sorte que ce code de déclencheur (SQL) pourrait également être généré pour toutes les tables existantes.

Il y aurait potentiellement beaucoup de code de script SQL (en fonction du nombre de tables), mais comme il s'agit d'un modèle reproductible, vous pouvez le générer en consultant un schéma de base de données existant.