SQL - Conception de table - Colonnes DateCreated et DateUpdated

Question

Pour mon application, il existe plusieurs classes d'entités, Utilisateur, Client, Poste, etc.

Je suis sur le point de concevoir la base de données et je souhaite stocker la date à laquelle les entités ont été créées et mises à jour. C'est là que ça devient délicat. Une option consiste à ajouter des colonnes created_timestamp et update_timestamp pour chacune des tables d’entités, mais cela n’est-il pas superflu?

Une autre possibilité pourrait être de créer une table de journal qui stockerait ces informations, afin de pouvoir conserver une trace des mises à jour de n'importe quelle entité.

Des pensées? Je me penche sur la mise en œuvre de ce dernier.

Answer 1

L'approche avec une seule table de log pour toutes les tables présente deux problèmes principaux auxquels je peux penser:

1. La conception de la table de journalisation va (probablement) contraindre la conception de toutes les autres tables. Il est fort probable que la table de journal aura une colonne nommée TableName, puis une autre colonne nommée PKValue (qui stockera la valeur de la clé primaire pour l'enregistrement que vous vous connectez). Si certaines de vos tables ont des clés primaires composées (c’est-à-dire plus d’une colonne), la conception de votre table de journalisation devra en tenir compte (probablement en ayant des colonnes telles que PKValue1, PKValue2, etc.).
2. S'il s'agit d'une application Web, l'identité de l'utilisateur qui serait disponible à partir d'un déclencheur serait le compte de l'application, au lieu de l'ID de l'utilisateur de l'application Web (ce qui est probablement ce que vous voulez vraiment stocker. dans votre champ CreatedBy). Cela ne ferait que vous aider à distinguer les enregistrements créés par le code de votre application Web des enregistrements créés autrement.

Les colonnes CreatedDate et ModifiedDate ne sont pas redondantes simplement parce qu'elles sont définies dans chaque table. Je m'en tiens à cette approche et mets des déclencheurs d'insertion et de mise à jour sur chaque table pour remplir ces colonnes. Si j’avais également besoin d’enregistrer l’utilisateur final qui a effectué la modification, j’ignorerais les déclencheurs et remplirait les champs d’horodatage et d’utilisateur de mon code d’application.

Answer 2

Je fais ce dernier, avec un "journal". ou " événements " table. D'après mon expérience, le " mis à jour " L’horodatage devient rapidement frustrant, parce que souvent, vous vous retrouvez dans une solution qui ne vous intéresse pas uniquement à la dernière mise à jour.

Answer 3

À quelle fréquence devrez-vous inclure les horodatages créés / mis à jour dans votre couche de présentation? Si la réponse est plus que "une fois dans un très bon moment", je pense que vous seriez mieux servi en disposant ces colonnes dans chaque tableau.

Answer 4

Sur un projet sur lequel j'ai travaillé il y a quelques années, nous avons implémenté des déclencheurs qui ont mis à jour ce que nous appelions une table d'audit (elle stockait des informations de base sur les modifications apportées, une table d'audit par table). Cette date de modification incluse (et la dernière modifiée).

Ils ont été appliqués uniquement aux tables de clés (pas aux jointures ni aux tables de données de référence).

Cela a supprimé une grande partie de la frustration normale de devoir prendre en compte LastCreated & amp; LastModified, mais introduit la gêne de maintenir les déclencheurs à jour.

En fin de compte, la conception de la table de déclenchement / d’audit a bien fonctionné et tout ce dont nous devions nous souvenir était de supprimer et de réappliquer les déclencheurs avant ETL (!).

Answer 5

Il s’agit d’un CMS Web sur lequel je travaille. Les dates de création et de dernière mise à jour seront affichées sur la plupart des pages et il y aura des listes pour les dernières pages créées (et mises à jour). L’interface administrateur utilisera également ces informations.