Uma tabela de log deve obter um campo de ID ou chave primária?

Eu tenho uma tabela de log que captura o carimbo de data e hora de quando determinados arquivos foram exportados para outro sistema.

A tabela exportedLog atualmente possui três campos:

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

Revendo isso, descobri que o idcampo não serve para nada, pois não há junções nessa tabela. A única coisa que trabalha nessa tabela é a inserção do trabalho em lotes que processa as mensagens e as insere nessa tabela de log.

Devo remover o idcampo?

Devo ter uma chave primária em ambos messageIdou exportedDateTimeou ambos?

Devo remover o campo de identificação?

Eu recomendaria mantê-lo.

Talvez você não precise do campo agora , mas no futuro ele poderá realmente ajudá-lo - e se você precisar armazenar detalhes dos arquivos para cada entrada de log?

Não sei quão grande essa tabela ficará e com que rapidez, mas adicionar uma coluna a uma tabela grande normalmente é uma operação cara. Se a tabela é relativamente pequena, não é muito importante manter em termos de espaço de armazenamento. IMO, mantenha a coluna e salve uma dor de cabeça em potencial mais tarde.

Devo ter uma chave primária em messageId ou exportedDateTime ou em ambos?

Não parece que messageIdsozinho seria único nesta tabela (embora eu possa estar errado), e a criação de exclusividade apenas em uma coluna de data / hora pode potencialmente criar duplicatas (e, portanto, erros). A única opção que resta é uma chave de 2 colunas, o que não é particularmente atraente, considerando o cenário exposto acima.

Essencialmente, meu ponto de resposta é que manter a coluna não é um grande problema (suponho), mas precisar mais tarde pode ser um grande problema e / ou exigir trabalho extra para recuperá-lo.

• Se você não possui junções nesta tabela, nenhuma atualização e exclusão, não precisa de chaves.

• Se esse não for o caso e messageIdfor exclusivo, você poderá torná-lo uma chave primária.

• Se não for exclusivo, mas (messageId, exportedDateTime)for, faça desta uma chave primária composta.

• Se até mesmo a (messageId, exportedDateTime)combinação pode dar duplicatas e atualizações e pode ser necessário exclusões (dizer para remover linhas inseridas acidentalmente), é melhor deixar o idcampo como está.

Uma Chave Primária não será prejudicada ... se você considerar o objetivo da trilha de log / auditoria, ela provavelmente será usada (consultada) no futuro para resolver um problema ou restaurar dados etc., e provavelmente será associada a outra tabelas não log / auditoria existentes para executar esse tipo de trabalho.