Oi pessoal!
Preciso da opinião de pessoas experientes com bancos de dados.
Qual a melhor forma de preencher campos de created_at e updated_at?
Procurei tirar essa dúvida pesquisando por diversas fontes como Chat-GPT e Google, mas cada uma recomenda uma estrateǵia diferente. Isso é bom, mas como eu não tenho tanta experiência é dificil de chegar em uma conclusão.
Gostaria de ouvir a opnião de vocês.
Chegando um pouco atrasado, mas enfim...
Sério que nenhuma IA te mostrou o mais óbvio e simples? Segue um exemplo em MySQL:
CREATE TABLE TEST (
id INT NOT NULL PRIMARY KEY,
value VARCHAR(10),
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP NULL DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP
);
Pronto, sem trigger nem complicações desnecessárias, apenas a definição de colunas com valores default na inserção ou atualização.
No caso, created_at não pode ser nulo, então se vc não informar um valor no INSERT, ele usará a data atual. Ou seja, se eu fizer:
INSERT INTO TEST(id, value) VALUES (1, 'abc');
A tabela ficará assim:
| id | value | created_at | updated_at |
|---|---|---|---|
| 1 | abc | 2025-04-02 10:56:12 |
Repare que eu não informei o created_at, então ele assume o valor default, que é a data atual (CURRENT_TIMESTAMP).
Já updated_at pode ser nulo, e somente no UPDATE ele é setado para a data atual.
Ou seja, se seu fizer:
UPDATE test SET value='xyz' WHERE id=1;
Agora a tabela fica assim:
| id | value | created_at | updated_at |
|---|---|---|---|
| 1 | xyz | 2025-04-02 10:56:12 | 2025-04-02 11:00:05 |
Repare que o campo updated_at não foi informado no UPDATE, sendo assim ele é automaticamente alterado para o valor definido na definição da coluna (que no caso também é a data atual).
E pronto. Outros bancos também possuem este recurso, talvez mude um pouquinho a sintaxe, mas a ideia é a mesma: na própria definição da tabela, informar os valores default para inserção ou atualização. Eu usaria triggers somente se o banco não tivesse tal recurso (alguns possuem somente para inserção, por exemplo), caso contrário estaria complicando à toa (ou, se o sistema for muito simples, setar as datas manualmente mesmo).
Por fim, sobre o uso de IA's: se nenhuma te sugeriu isso, talvez seja porque elas ainda não estão tão boas assim, ou então vc que não soube fazer a pergunta correta (não dá pra saber qual foi, e talvez seja até uma combinação de ambos).
Aqui temos um exemplo bem interessante que vou abordar um dia com mais profundidade em um exercício de socio/psicologia.
A pessoa usou várias IAs para ajudar ter uma informação melhor, o que é bomk. As IAs deram respostas divergentes e a pessoa então ficou confusa e preferiu perguntar para humanos qual é o certo, o que é bom.
Mas e se a pessoa escolhesse uma delas sem perguntar para um humano? Se as respostas não fossem divergentes? Se ela não tivesse usado mais que uma?
Se a resposta fosse ruim, teríamos um caso clássico de IA piorando o s=desenmpenho do ser humano. E aco nteceria mesmo porque as pessoas que não são extremamente experientes, não só em tempo, mas em qualidade, aceitariam o fato como certo porque ele funcionou (já vi usuários teoricamente experiente argumentar comigo que eu estava errado porque o que ele fez foi aceito pelo compulador), mesmo que não fosse adequado. Este caso me parece que todos funcionariam, inclusive de algumas respostas, mas não é certo. Sim, existe um certo, algumas coisas que funcionam mas não é o certo e infinitas que sequer funcionam, o que é a parte boa.
Então conluímos algumas coisas:
Reforço, você tem que usar IA para ser mais produtivo, mas é só isso, ela deve ser usada como calculadora, nada mais. Você continua tendo quer ser pica no que está fazendo, tem que aprender por fontes confiáveis, precisa aceitar que tem momentos que a IA te deixará na mão e você precisa resolver o problema sem ela, e que ela não vai melhorar tanto quanto alguns falam. A´te vai melhorar mais um pouco algumas mais específicas.
Devemos tomar mais cuidado com os resultados positivos dela, porque isso vai criando a ilusão que ela é boa. Eu tendo isso muito consciente na cabeça me pego caindo na armadilha.
S2
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).
Muito boa essa estratégia, não conhecia.
Mas precisamos tomar alguns cuidados em relação a isso.
Por exemplo, será que é necessário realizar a alteração da updated_at toda vez que tiver uma atualização no registro, mesmo que essa alteração seja uma manutenção manual?
Fazer com trigger poderia cair no mesmo dilema, por isso, muitas vezes prefiro que a aplicação tome conta disso.
Se não for na camada da aplicação, você pode usar triggers na base de dados. Na camada da aplicação, normalmente os principais ORMs do mercado possuem mecanismos para isso.
Caso não possa contar nem com uma coisa e nem com outra, então precisa ajustar seus SQL para adicionar essa funcionalidade.
Ouvi dizer que os triggers podem comprometer a performace do banco ao longo prazo, ainda mais depois que tiver muitos usuários fazendo alterações. É verdade isso?
As triggers comuns são mais rápidas do que qualquer solução que você implemente no seu código.
O que pode deixar lento é se você colocar uma grande operação dentro da função definida na trigger, tem muita aplicação feita por profissionais pouco qualificados que basicamente programam o sistema inteiro baseados em triggers e functions no banco de dados. Lido com aplicações assim constantemente.
Se colocar apenas para mudar dois campos do registro que está sendo modificado, o tempo que vai levar é o mesmo que o insert ou update já leva. A aplicação não vai sentir a diferença.
Mas tenha cuidado para não fazer um update dentro de uma trigger da própria tabela, faça a alteração dos valores que estão chegando. No Oracle, por exemplo, você pode alterar os valores da variável NEW, pesquise sobre isso que você vai entender o que eu estou falando.
Não existe uma resposta suprema em quase nada relacionado a programação. Tudo é um grande depende orientado ao contexto. O seu contexto não ficou claro, no caso seria via aplicação? Se sim, o modo mais cru disso, seria no momento da ação. Se criou o registro preenche o created_at, se editou, preenhe o updated_at... Como ja falaram, alguns frameworks já tratam isso por via do seu ORM.
Poderia me dizer qual a vantagem de fazer esse manejamento em nível de aplicação? Eu tava pensando em fazer em nível de banco.
Created_at e updated_at são apenas campos que podem ser preenchidos no momento da ação de criar ou editar o registro. Eu delegaria ao banco, se eu tivesse que alterar varias outras tabelas que dependem dessa informação do registro expessifico. Se tiver que criar uma rotina no banco somente para registrar esses dados, meio que não faz muito sentido. Porem, o que vale é o motivo que precisa pra fazer isso. Ou seja, nem certo e nem errado, apenas formas diferentes de se fazer. Uma mais desgastante do que a outra. Mas tudo depende do motivo.
Da mesma forma que você eu tmb delegaria essa tarefa ao banco, mas conheço gente experiente que ABOMINA trigger em banco de dados e eu não sei o porque. Pra mim parece ser uma mão na roda criar trigger para esses tipos de tarefas.
Com o tempo, a gente entende que os extremos raramente funcionam. Nem tanto ao norte, nem tanto ao sul.
Quando algo é bem feito, dá certo — simples assim.
Usar triggers no banco, por exemplo, não é algo sem propósito. Elas existem para resolver problemas específicos do dia a dia, da equipe ou do projeto. Mas, como tudo na tecnologia, precisam ser usadas com sabedoria.
Sempre vão existir pessoas que preferem a abordagem A ou B. E tudo bem! O importante é reconhecer que, na prática, tudo pode ser útil — e tudo pode dar certo ou errado. Depende de como foi feito, do contexto e da necessidade real.
No caso, esses campos não ficam em tela, mas lá no seu back-end, antes de salvar o registro, voce seta essa informação do campo.