Una tabella di registro dovrebbe ottenere un campo ID o chiave primaria?

Ho una tabella di registro che cattura il timbro datetime di quando alcuni file sono stati esportati su un altro sistema.

La tabella exportedLog attualmente ha tre campi:

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

Revisionando questo ho scoperto che il idcampo non serve a nulla, poiché non ci sono join in questa tabella. L'unica cosa che funziona su questa tabella è l'inserimento del processo batch che elabora i messaggi e inserisce in questa tabella di registro.

Devo rimuovere il idcampo?

Dovrei avere una chiave primaria su entrambi messageIdo exportedDateTimeo entrambi?

Devo rimuovere il campo ID?

Consiglierei di tenerlo.

Potrebbe non essere necessario il campo ora , ma in futuro può davvero aiutarti - cosa succede se è necessario memorizzare i dettagli dei file per ogni voce del registro?

Non so quanto sarà grande questa tabella e quanto velocemente, ma l'aggiunta di una colonna a una tabella di grandi dimensioni è in genere un'operazione costosa. Se la tabella è relativamente piccola, non è un grosso problema da conservare in termini di spazio di archiviazione. IMO, mantieni la colonna e salva un potenziale mal di testa in seguito.

Dovrei avere una chiave primaria su messageId o exportedDateTime o su entrambi?

Non sembra che messageIdda solo sarebbe unico in questa tabella (anche se potrei sbagliarmi) e creare unicità su una sola colonna data / ora può potenzialmente creare duplicati (e quindi errori). L'unica opzione rimasta è una chiave a 2 colonne, che non è particolarmente interessante dato lo scenario che ho esposto sopra.

In sostanza, il mio punto di questa risposta è che mantenere la colonna non è un grosso problema (presumo), ma averne bisogno in seguito potrebbe essere un grosso problema e / o richiedere un lavoro extra per rimetterlo.

• Se non hai join in questa tabella, nessun aggiornamento e nessuna eliminazione, non hai bisogno di chiavi.

• In caso contrario, ed messageIdè univoco, è possibile renderlo una chiave primaria.

• Se non è univoco, ma lo (messageId, exportedDateTime)è, rendilo una chiave primaria composita.

• Se anche la (messageId, exportedDateTime)combinazione può fornire duplicati e potrebbero essere necessari aggiornamenti ed eliminazioni (diciamo per rimuovere le righe inserite accidentalmente), è meglio lasciare il idcampo così com'è.

Una chiave primaria non danneggerà ... se si considera lo scopo del registro / audit trail, sarà probabilmente utilizzata (interrogata) in futuro per risolvere un problema o ripristinare i dati, ecc. E probabilmente verrà unita ad altri tabelle esistenti non di log / audit per eseguire quel tipo di lavoro.