Une table de journal doit-elle obtenir un champ id ou une clé primaire?

J'ai une table de journal qui capture l'estampille datetime lorsque certains fichiers ont été exportés vers un autre système.

La table exportsLog comporte actuellement trois champs:

id                (primary key)
messageId         (int)
exportedDateTime  (datetime)

En examinant cela, j'ai trouvé que le idchamp ne sert à rien, car il n'y a aucune jointure à cette table. La seule chose qui fonctionne sur cette table est l'insertion du travail par lots qui traite les messages et les insère dans cette table de journal.

Dois-je supprimer le idchamp?

Dois - je avoir une clé primaire de chaque messageIdou exportedDateTimeou les deux?

Dois-je supprimer le champ id?

Je recommanderais de le garder.

Vous n'avez peut-être pas besoin du champ maintenant , mais à l'avenir, cela peut vraiment vous aider - que faire si vous avez besoin de stocker les détails des fichiers pour chaque entrée de journal?

Je ne sais pas quelle taille cette table obtiendra et à quelle vitesse, mais l'ajout d'une colonne à une grande table est généralement une opération coûteuse. Si la table est relativement petite, ce n'est pas un gros problème à conserver en termes d'espace de stockage. OMI, gardez la colonne et enregistrez un mal de tête potentiel plus tard.

Dois-je avoir une clé primaire sur messageId ou exportsDateTime ou les deux?

Il ne semble pas que messageIdseul serait unique dans ce tableau (bien que je puisse me tromper), et la création d'unicité sur une colonne date / heure seule peut potentiellement créer des doublons (et donc des erreurs). La seule option qui reste est une clé à 2 colonnes, ce qui n'est pas particulièrement attrayant compte tenu du scénario que j'ai exposé ci-dessus.

Essentiellement, mon point de vue de cette réponse est que garder la colonne n'est pas un gros problème (je suppose), mais en avoir besoin plus tard peut être un gros problème et / ou nécessiter un travail supplémentaire pour le remettre.

• Si vous n'avez pas de jointures sur cette table, pas de mises à jour et pas de suppressions, alors vous n'avez absolument pas besoin de clés.

• Si ce n'est pas le cas et messageIdest unique, vous pouvez en faire une clé primaire.

• Si ce n'est pas unique, mais l' (messageId, exportedDateTime)est, faites-en une clé primaire composite.

• Si même la (messageId, exportedDateTime)combinaison peut donner des doublons et des mises à jour et des suppressions peuvent être nécessaires (par exemple pour supprimer des lignes insérées accidentellement), vous feriez mieux de laisser le idchamp tel quel.

Une clé primaire ne fera pas de mal ... si vous considérez le but du journal / journal d'audit, il sera probablement utilisé (interrogé) à l'avenir pour résoudre un problème ou restaurer des données, etc. et sera probablement joint à d'autres des tables existantes non enregistrées / d'audit pour effectuer ce type de travail.