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 id
campo não serve para nada, pois não há junções para esta tabela. A única coisa que funciona nesta tabela é a inserção do trabalho em lote que processa as mensagens e insere nesta tabela de log.
Devo remover o id
campo?
Devo ter uma chave primária em um messageId
ou em exportedDateTime
ambos?
Eu recomendaria mantê-lo.
Você pode não precisar do campo agora , mas no futuro ele pode realmente ajudá-lo -- e se você precisar armazenar detalhes dos arquivos para cada entrada de log?
Não sei o tamanho dessa tabela e com que rapidez, mas adicionar uma coluna a uma tabela grande geralmente é uma operação cara. Se a tabela for relativamente pequena, não é um grande problema mantê-la em termos de espaço de armazenamento. IMO, mantenha a coluna e poupe uma possível dor de cabeça mais tarde.
Não parece que
messageId
sozinho seria único nesta tabela (embora eu possa estar errado), e criar 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 devido ao cenário que descrevi acima.Essencialmente, meu ponto desta resposta é que manter a coluna não é grande coisa (estou assumindo), mas precisar dela mais tarde pode ser um grande problema e/ou exigir trabalho extra para colocá-la de volta.
Se você não tiver junções nesta tabela, nenhuma atualização e nenhuma exclusão, então você não precisa de nenhuma chave.
Se esse não for o caso e
messageId
for exclusivo, você poderá torná-lo uma chave primária.Se não for exclusivo, mas
(messageId, exportedDateTime)
for, torne-o uma chave primária composta.Se até mesmo a
(messageId, exportedDateTime)
combinação pode fornecer duplicatas e atualizações e exclusões podem ser necessárias (digamos, para remover linhas inseridas acidentalmente), é melhor deixar oid
campo como está.Uma Chave Primária não vai doer... se você considerar o propósito da trilha de log/auditoria, ela provavelmente será usada (consultada) no futuro para resolver um problema ou restaurar dados, etc. tabelas existentes que não são de log/auditoria para realizar esse tipo de trabalho.