Quando uma tabela de banco de dados deve usar registros de data e hora?

Primeiro, observei que talvez essa pergunta pertencia à troca de banco de dados, mas acho que está mais amplamente relacionada a uma solução de programação como um todo do que a bancos de dados. Passará para a troca de banco de dados se as pessoas acharem que é a melhor.

Eu queria saber quando uma tabela de banco de dados deve ter um carimbo de data / hora criado e atualizado adicionado?

A primeira resposta óbvia é que, se alguma lógica de negócios precisar saber quando algo foi atualizado (como uma data de conclusão da transação, etc.), deve entrar.

Mas e os casos de lógica não comercial? Por exemplo, posso pensar em cenários em que seria realmente útil saber a data e hora em que as linhas foram alteradas para ajudar na localização de falhas, por exemplo, alguma lógica de negócios está falhando e, olhando as linhas do banco de dados relacionadas, é possível identificar que uma linha está sendo atualizada antes outra linha que está causando o erro.

Com esse caso de uso, faria sentido atualizar todas as tabelas e criar um registro de data e hora (exceto talvez as tabelas de enumeração mais triviais que não seriam atualizadas por nenhuma parte do aplicativo).

Dar a cada tabela um carimbo de data / hora é certamente uma ótima maneira de atolar rapidamente um banco de dados (embora possa estar errado).

Então, quando uma tabela de banco de dados deve usar criar e atualizar registros de data e hora?

Para um gerenciamento de banco de dados melhor e mais abrangente, a prática mais sábia é fazer isso.

Primeiro, é mais provável que, como desenvolvedor, você deseje acompanhar as transações e / ou atividades do banco de dados para desenvolvimento e facilitar o rastreamento de bugs e erros no seu código sempre que ele envolver o banco de dados.

Além disso, sempre que você precisar acompanhar as atividades realizadas em seu banco de dados para fins estatísticos .

Outra coisa é que, por enquanto, talvez você não precise acompanhar as atividades do banco de dados, mas é mais provável que você faça isso no futuro. Vai precisar do seu tempo hoje, mas você compra mais no futuro .

Como alguém que foi caçador (desenvolvedor) e guarda-game (DBA), estou surpreso que muitos ainda não vêem o valor nisso e o consideram inchado.

Simplificando:

Para qualquer tabela em que os registros são adicionados (mas nunca atualizados), por exemplo, logins etc., eu consideraria adicionar uma coluna DATE_CREATED.

Para qualquer tabela em que os registros sejam adicionados e atualizados, eu consideraria adicionar uma coluna DATE_CREATED e DATE_UPDATED.

Já trabalhei em muitos lugares onde DATE_CREATED e DATE_UPDATED estão incluídos em todas as tabelas por padrão como parte do design.

Para bancos de dados maiores com milhões / bilhões de linhas em que a atualização do banco de dados foi executada ao longo de alguns dias, também adicionamos uma coluna SOURCE para algumas tabelas que rastreiam qual pote de dados causou a atualização, por exemplo, feed de terceiros, atualização do usuário, modificação do DBA, limpeza de dados etc.

Do jeito que a pergunta está formulada, você está pedindo uma lista de coisas. Vou arriscar não responder diretamente à sua pergunta, mas responder quando você deve usar uma solução alternativa.

Posso pensar em cenários em que seria realmente útil saber a data e hora em que as linhas foram alteradas para ajudar na localização de falhas

Seria mais útil ter um log de todas as atualizações para um determinado registro? Apenas conhecer a última atualização, pode não ser informação suficiente. Esse log pode ser colocado em uma tabela separada. Seria mais conveniente rastrear alterações de várias tabelas no (s) mesmo (s) arquivo (s) de registro (não precisa ser uma tabela). Isso evita que algumas consultas de união massivas de todas as datas de alteração de tabela sejam agregadas. Isso também beneficiaria a solução de problemas, ajudando você a ver uma gravação de mais eventos em seu sistema.

Além disso: você também deve considerar os usuários. Eles podem não torná-lo um caso de negócios, mas quando você tem usuários inexperientes ou em uma cultura corporativa em que nunca cometem um erro do usuário e desejam sempre culpá-lo no computador, qualquer tipo de registro ajudará, incluindo datas de atualização nas tabelas. Nesse caso, convém ter um campo Update_UserID também.

Uma tabela de banco de dados deve incluir modelos de criação e modificação quando um dos seguintes for verdadeiro:

1. A tabela representa um registro primário de alguma atividade fornecida pelo usuário. Se o usuário fizer X e você tiver um Table_Xe um Table_Yfilhos de um para muitos Table_X, Table_Ynão será um registro primário e, portanto, não precisará de campos extras.
2. Quando você tem uma necessidade permanente, temporária ou recorrente de rastreamento do sistema . Se você precisar verificar se Table_Yapenas é atualizado quando Table_Xé atualizado, os campos de rastreamento extras podem ajudar.

Observe que nenhum deles é exclusivo; você pode prosseguir e adicioná-los a todos os lugares por padrão e omitir apenas quando necessário para ajuste de desempenho.

Opinião pessoal:

Não vejo o valor em uma modifiedcoluna.

created, absolutamente, deve ser adicionado a todas as tabelas do banco de dados, a menos que haja uma justificativa excepcional para não fazer isso. Há muito valor em tê-lo lá.

No entanto, updatedparece um desperdício. Por que não fazer o trabalho todo, crie duas tabelas de banco de dados, uma que especifique um ID do documento e outra a versão do documento. Em um caso muito simplista

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
);

Em seguida, selecione o mais recente versiondo documentque você deseja. Dessa forma, você não apenas salva todas as datas de modificação - não apenas a última - mas também mantém todas as versões desse documento. O único argumento contra isso é realmente o espaço no disco rígido, mas certamente quando você chega ao ponto de se preocupar com o espaço que está consumindo - na maioria dos casos, você se preocupa ainda mais com a versão dos dados