web-dev-qa-db-fra.com

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, par exemple. une logique métier échoue et en examinant les lignes de base de données associées, il est possible d'identifier qu'une ligne est en cours de mise à jour avant une autre ligne à l'origine de 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?

databasedatabase-designmysqldebugginglogging
19
Gaz_Edge

Pour une meilleure et plus gestion complète de la base de données 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 suivre les transactions et/ou 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 pour à 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 fassiez à l'avenir. Il aura besoin de votre temps aujourd'hui, mais vous en achètera plus à l'avenir.

5
Leon Alexis Cardinal

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 identifiants, 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 par défaut dans chaque table 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 Flux tiers, mise à jour utilisateur, modification DBA, nettoyage des données, etc.

16
Robbie Dee

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 le ou 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.

6
JeffO

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_X Et un Table_Y Qui sont des enfants un-à-plusieurs de Table_X, Table_Y N'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 Table_Y N'est mis à jour que lorsque Table_X Est mis à 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.

1
DougM

Opinion personnelle:

Je ne vois pas la valeur dans une colonne modified.

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

Cependant, updated semble 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 le dernier version du document souhaité. De cette façon, non seulement vous enregistrez chaque date de modification - pas seulement la dernière - mais vous gardez également chaque version de ce document. Le seul argument contre cela est vraiment l'espace sur le disque dur, mais quand vous arrivez au point où vous êtes inquiet de l'espace disque utilisé - dans la plupart des cas, vous seriez encore plus gêné sur la version des données

1
Algy Taylor