Quand une table de base de données doit-elle utiliser des horodatages?

Tout d'abord, je pensais que cette question appartenait peut-être à l'échange de bases de données, mais je pense qu'elle est plus largement liée à une solution de programmation dans son ensemble qu'aux bases de données. Passera à l'échange de bases de données si les gens pensent que c'est le meilleur.

Je me demandais quand une table de base de données devrait avoir un horodatage créé et mis à jour ajouté?

La première réponse évidente est que si une logique métier a besoin de savoir quand quelque chose a été mis à jour (comme une date d'achèvement de transaction, etc.), elle doit entrer.

Mais qu'en est-il des cas de logique non commerciale? Par exemple, je peux penser à des scénarios où il serait vraiment utile de connaître la date et l'heure de modification des lignes pour aider à la recherche de pannes. une autre ligne qui provoque l'erreur.

Avec ce cas d'utilisation, il serait logique de mettre à jour chaque table et de créer un horodatage (à l'exception peut-être des tables d'énumération les plus triviales qui ne seraient mises à jour par aucune partie de l'application).

Donner à chaque table un horodatage est certainement un excellent moyen d'enliser rapidement une base de données (bien que cela puisse être faux).

Alors, quand une table de base de données doit-elle créer et mettre à jour des horodatages?

Pour une gestion de base de données meilleure et plus complète et la pratique la plus sage est de le faire.

Tout d'abord, il est plus probable qu'en tant que développeur, vous souhaitiez avoir une trace des transactions et / ou des activités de base de données pour le développement et faciliter le suivi des bogues et des erreurs sur votre code chaque fois qu'il implique votre base de données.

Aussi, chaque fois que vous avez besoin de suivre les activités effectuées sur votre base de données à des fins statistiques .

Un autre, c'est qu'il arrive souvent que, pour le moment, vous n'ayez pas besoin de suivre les activités de votre base de données, mais il est plus probable que vous le feriez à l'avenir. Il aura besoin de votre temps aujourd'hui, mais vous en achètera davantage à l'avenir .

En tant que quelqu'un qui a été à la fois braconnier (développeur) et garde-chasse (DBA), je suis surpris que beaucoup ne voient toujours pas la valeur de cela et le considèrent comme ballonné.

Tout simplement:

Pour toute table où des enregistrements sont ajoutés (mais jamais mis à jour), par exemple les connexions, etc., j'envisagerais d'ajouter une colonne DATE_CREATED.

Pour toute table où des enregistrements sont ajoutés et mis à jour, j'envisagerais d'ajouter une colonne DATE_CREATED et DATE_UPDATED.

J'ai travaillé à de nombreux endroits où DATE_CREATED et DATE_UPDATED sont inclus dans chaque table par défaut dans le cadre de la conception.

Pour les bases de données plus grandes avec des millions / milliards de lignes où la mise à jour de la base de données s'est déroulée sur quelques jours, nous avons également ajouté une colonne SOURCE pour certaines tables qui suivaient le pot de données à l'origine de la mise à jour, par exemple le flux tiers, la mise à jour utilisateur, la modification DBA, nettoyage des données, etc.

La façon dont la question est formulée, vous demandez une liste de choses. Je vais risquer non pas de répondre directement à votre question, mais de savoir quand vous devriez utiliser une autre solution.

Je peux penser à des scénarios où il serait vraiment utile de connaître l'heure à laquelle les lignes ont changé pour aider à la recherche de pannes

Serait-il plus utile d'avoir un journal de toutes les mises à jour pour un enregistrement donné? La simple connaissance de la dernière mise à jour peut ne pas suffire. Ce journal peut être placé dans un tableau séparé. Il serait plus pratique de suivre les modifications de plusieurs tables dans les mêmes fichiers journaux (il ne doit pas nécessairement s'agir d'une table). Cela empêche une requête d'union massive de toutes les dates de changement de table pour obtenir des agrégats. Cela bénéficierait également au dépannage en vous aidant à voir un enregistrement de plus d'événements dans votre système.

De plus: vous devez également tenir compte des utilisateurs. Ils ne peuvent pas en faire une analyse de rentabilisation, mais lorsque vous avez des utilisateurs inexpérimentés ou ceux dans une culture d'entreprise où ils ne font jamais d'erreur et veulent toujours le blâmer sur l'ordinateur, tout type de journalisation aidera, y compris les dates de mise à jour sur les tables. Dans ce cas, vous souhaiterez peut-être également avoir un champ Update_UserID.

Une table de base de données doit inclure des modèles de création et de modification lorsque l'une des conditions suivantes est vraie:

1. Le tableau représente un enregistrement principal d'une activité fournie par l'utilisateur. Si l'utilisateur fait X, et que vous avez à la fois un Table_Xet un Table_Yqui sont des enfants un à plusieurs Table_X, Table_Yn'est pas un enregistrement principal et n'a donc pas besoin des champs supplémentaires.
2. Lorsque vous avez un besoin permanent, temporaire ou récurrent de suivi du système . Si vous avez besoin de vérifier que la Table_Ymise à Table_Xjour n'est effectuée que lorsqu'elle est mise à jour, les champs de suivi supplémentaires peuvent vous aider.

Notez qu'aucun de ces éléments n'est exclusif; vous pouvez continuer et les ajouter partout par défaut, et ne les omettre qu'en cas de besoin pour l'optimisation des performances.

Opinion personnelle:

Je ne vois pas la valeur dans une modifiedcolonne.

created, absolument, devrait être ajouté à chaque table de base de données, sauf s'il existe une justification exceptionnelle pour ne pas le faire. Il y a tellement de valeur à l'avoir là-bas.

Cependant, updatedsemble un gaspillage. Pourquoi ne pas simplement passer tout le porc, créer deux tables de base de données, une qui spécifie un ID de document et une autre la version du document. Dans un cas très simpliste

create table document (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

create table version (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    document_id INT NOT NULL REFERENCES document(id),
    content TEXT NOT NULL,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

Sélectionnez ensuite la dernière versionde celles que documentvous souhaitez. De cette façon, non seulement vous enregistrez chaque date de modification - pas seulement la dernière - mais vous conservez également chaque version de ce document. Le seul argument contre cela est vraiment l'espace disque dur, mais sûrement lorsque vous arrivez au point où vous êtes dérangé par l'espace disque qu'il utilise - dans la plupart des cas, vous seriez encore plus gêné par la version des données