Faz sentido padronizar, incluindo um campo de data de criação e data da última atualização em todas as tabelas de banco de dados?

Meu chefe está atualmente tentando aplicar alguns padrões de desenvolvimento à nossa equipe, então tivemos uma reunião ontem para discutir os padrões que estavam indo muito bem até que ela falou:

• Todas as tabelas de banco de dados terão uma coluna CreatedDate e LastUpdatedDate, atualizada por gatilhos.

Nesse ponto, nossa equipe sofreu um cisma de opinião; metade de nós acha que fazer isso em todas as tabelas é uma grande quantidade de trabalho com pouco benefício (trabalhamos em projetos de orçamento fixo, para que qualquer custo provenha dos lucros de nossa empresa); a segunda metade acredita que ajudará no apoio aos projetos.

Estou firmemente no antigo campo. Embora eu aprecie que alguns casos externos façam com que as colunas extras melhorem o suporte, na minha opinião, a quantidade de trabalho necessária para adicionar as colunas em primeiro lugar, bem como a manutenção, nos levaria a gastar menos tempo em mais coisas importantes, como testes de unidade ou de carga. Além disso, tenho certeza de que essas colunas extras tornariam mais complicado o uso de um ORM - tendo em mente que usamos principalmente C # e Oracle, o que não é muito bom para ORM no início.

Então, minha pergunta é dupla:

• Estou no acampamento certo? Não pretendo ter habilidades de banco de dados de renome mundial; portanto, essa pode ser uma adição trivialmente fácil, sem efeitos colaterais adversos.
• Como você lidaria com uma situação em que uma reunião sobre padrões se transforma em uma disputa de escória? Como posso realmente vender que esse padrão não vai nos ajudar a longo prazo?

Essa é uma prática bastante comum, embora eu não diria que a capacidade de suporte é o principal benefício. O benefício real dessa abordagem é manter uma trilha de auditoria. Também é um local comum ter uma coluna extra contendo o nome de usuário do usuário que fez a última atualização.

Se você estiver lidando com qualquer tipo de dados financeiros ou sensíveis, tenho certeza de que já ouviu falar de coisas como conformidade com PCI e SOX . Ter uma trilha de auditoria abrangente é essencial para atender a essas especificações.

Isenção de responsabilidade: No entanto, existem maneiras muito melhores de obter uma trilha de auditoria do banco de dados> https://stackoverflow.com/questions/1051449/ideas-on-database-design-for-capturing-audit-trails

O argumento anterior é inválido, porque adicionar alguns campos de carimbo de data / hora mantidos no banco de dados a uma série de tabelas não é um trabalho difícil. Na verdade, esse é o tipo de tarefa entorpecente que alguém daria a um júnior ou a um estagiário, e eles poderiam fazer isso facilmente em uma única corrida de duas semanas, com tempo de sobra.

Pode ou não ser necessário mapear esses campos no ORM, simplesmente porque você não deseja que os usuários do aplicativo modifiquem esses campos e porque são úteis para manutenção e depuração e raramente têm uso na lógica de negócios. Eu trabalhei em lojas que fizeram as duas coisas e, francamente, não tenho muita opinião sobre isso.

Os benefícios, mesmo que exagerados, ainda superam em muito os custos humanos na implementação de tal funcionalidade no nível do banco de dados, e certamente provavelmente menos do que o poder coletivo do cérebro dos projetos de grandes mentes técnicas que sequestram a reunião e a disputam em uma luta épica no peito. Quando você calcula o impacto que algumas reuniões de 1 hora têm na vida útil de um projeto, você provavelmente não ficará surpreso que elas sejam caras. Imagine o salário horário coletivo e os benefícios de todas essas pessoas combinadas e isso deve lhe dar uma idéia.

... as declarações mais definitivas que um homem aumenta, é mais provável que ele esteja definitivamente errado ... - tyler durden

isso se aplica a "padrões" comuns, enquanto em algumas mesas isso pode ser uma grande vitória, em todas as mesas provavelmente haverá ruído inútil e mais código para manter ou esquecer de manter.

existe um equilíbrio aqui, é isso que você deve empurrar para os tomadores de decisão.

Eu concordo plenamente. Quase todas as tabelas em todos os bancos de dados devem ter pelo menos 2 campos: a data de criação e a data de atualização . Há muitos motivos para você colocar uma data de criação e uma data de atualização. Por razões óbvias que pessoas anteriores declararam ... que é auditoria.

Projecto sistemas e bases de dados há 25 anos e trabalhei para centenas de clientes. Não há um único cliente que NÃO precise disso.

Existem 2 maneiras básicas de fazer isso:

1 - A primeira prática é deixar o banco de dados fazer o trabalho e colocá-lo diretamente no design da tabela. Qual é o mínimo, eu recomendaria.

2 - A outra prática, que eu prefiro ... é usar uma ferramenta de replicação para lidar com isso. Há pouca sobrecarga e nenhum custo para as equipes de DEV. No entanto, as ferramentas são caras. Uma vantagem adicional é que o processo de exclusão pode ser auditado muito mais facilmente com esse tipo de ferramenta. Sem uma ferramenta de replicação, você precisaria criar uma tabela de auditoria e disparar disparos para exclusões - não é uma boa prática na minha opinião.

Outro benefício de ter esses campos é o data warehouse e o ODS que SEMPRE são criados para qualquer sistema OLTP. Você não pode efetivamente extrair dados incrementais sem eles. Caso contrário, você corre o risco de recarregar todo o banco de dados todos os dias.

Há um número enorme de outras razões comerciais para colocar essas duas datas, das quais não vou me aprofundar aqui. Faça sua lição de casa e tenho certeza de que, 3-6-12-48 meses depois, você ficará muito feliz em colocar nesses 2 campos simples.

Eu implementei e geralmente recomendo as duas soluções sempre que possível.

Temos a data de criação e as colunas do nosso banco de dados e elas nos ajudaram tremendamente a rastrear problemas de dados. Se precisarmos reverter, isso nos ajudará a encontrar os registros corretos nas tabelas de auditoria completas (porque sabemos onde procurar em uma tabela muito grande). Ela deve adicionar um criado por e modificado por colunas também. Realmente ajuda saber quem colocou os dados, especialmente se você não tiver uma auditoria completa.

Não consigo pensar em nenhum aplicativo corporativo que não precise de auditoria de uma forma ou de outra. Aparentemente, seu chefe acha que precisa apenas de uma auditoria relativamente leve. Pessoalmente, sou a favor da auditoria completa em todos os bancos de dados que contêm dados dos quais sua empresa depende (é muito mais fácil reverter esses 2.000 registros incorretos das tabelas de auditoria do que restaurar backups) e exigiria isso se houver alguma informação financeira, como eu vi esse tipo de coisa ajudar a pegar as pessoas que cometem fraudes. Toda a auditoria deve estar no nível do banco de dados.

Como esses dados podem ajudar? Bem, primeiro ele reduz quando procurar os dados antigos (em uma revisão) e pode ajudá-lo a ver qual versão do seu programa estava ativa no momento em que os dados foram inseridos. Portanto, se você sabe que resolveu esse problema na versão 2.3, que foi ao ar em 6 de julho de 2011 e encontrou o mesmo problema com um registro inserido em 7 de agosto, talvez sua correção não tenha sido boa. Se você precisar reverter para dados antigos, ele informará em qual versão dos backups você poderá encontrar os dados antigos se não tiver uma auditoria completa.

Os desenvolvedores raramente parecem pensar que os dados devem ser mantidos ao longo do tempo e que dados ruins precisam ser corrigidos por alguém. Ter coisas assim pode ser muito valioso para aqueles que precisam fazer essas coisas. Seu chefe está certo, embora eu não ache que ela foi longe o suficiente na auditoria. Leva apenas um problema realmente sério que é fácil de corrigir para justificar a quantidade muito pequena de tempo necessária para adicionar essas colunas e gatilhos.

A carga de trabalho é discutível porque isso pode ser script e aplicado a todos os bancos de dados que você criará. Adicione as colunas a todas as tabelas junto com os gatilhos. Você só precisa se lembrar de executá-lo com sua compilação.

Na medida em que o cliente deseja, você pode pagá-lo para integrá-lo ao seu aplicativo como bem entender. Muitos gostam de ver informações adicionais em um registro, como quem o criou / mudou por último e quando. Não é necessário enviar um email para todos para descobrir ou mentir. Você não precisa consultar um log toda vez que alguém olha para um registro.

Colocá-lo no banco de dados e tê-lo lá apenas por precaução não é tão difícil e pode permitir que você cobrar por recursos adicionais que utilizam os campos ou apenas para fornecer algum feedback sobre a quantidade de clientes que estão usando o sistema.

Seria uma implementação bastante trivial (talvez um a três dias no total), portanto, na minha opinião, é quanto valor será adicionado ao seu aplicativo ao longo da vida útil.

Primeiro, seria necessária uma instrução alter table para adicionar as colunas, a tabela alter seria a mesma (exceto o nome da tabela), para que você pudesse escrever um script para gerar a instrução SQL alter para todas as tabelas necessárias. . É necessário permitir que os NULLs considerem os dados existentes e verifique a existência das colunas para que sejam executáveis ​​novamente.

Segundo, para as colunas, o uso de valores padrão, como GetUTCDate () (SQL Server, Oracle, talvez diferente) resolve quaisquer adições de codificação na inserção, portanto, a base de código não precisa ser alterada para nenhuma das instruções de inserções, pois os valores padrão serão usava.

As atualizações de dados (alteração para a última modificação) podem ser resolvidas com um gatilho de atualização. Novamente, esse gatilho seria quase o mesmo em todas as tabelas, portanto esse código de gatilho (SQL) também poderia ser gerado para qualquer tabela existente.

Existe potencialmente muito código de script sql (dependendo de quantas tabelas), mas é um padrão que pode ser repetido; portanto, você pode gerá-lo por código observando um esquema de banco de dados existente.