Usando o
id sequencial seria mais simples, pois é provavelmente (?) uma chave primária e, portanto, indexada e mais rápida de acessar. Dado que você tem user_id , você pode confirmar rapidamente as edições anteriores e anteriores. Usando o
timestamp também é aplicável, mas é provável que seja uma entrada mais longa e não sabemos se está indexada, além do potencial de colisões. Você corretamente aponta que os relógios do sistema podem mudar... Considerando que o id sequencial não pode. Dada sua atualização:
Como é difícil ver quais são seus requisitos exatos, incluí isso como evidência do que um projeto específico exigia mais de 200 mil documentos complexos e milhões de revisões.
Da minha própria experiência (construindo um sistema de documentação/perfil totalmente auditável) para uma equipe interna de mais de 60 pesquisadores em tempo integral. Acabamos usando um
id e vários outros campos (incluindo timestamp ) para fornecer acompanhamento de auditoria e versão completa. O sistema que construímos tem mais de 200 campos para cada perfil e, portanto, a versão de um documento era muito mais complexa do que apenas armazenar um bloco de texto/conteúdo alterado para cada um; No entanto, cada perfil pode ser editado, aprovado, rejeitado, revertido, publicado e até exportado como PDF ou outro formato como UM documento.
O que acabamos fazendo (depois de muita estratégia/planejamento) foi armazenar versões sequenciais do perfil, mas elas foram digitadas principalmente em um
id campo . Carimbos de data e hora
Os carimbos de data/hora também foram capturados como uma verificação secundária e nos certificamos de manter os relógios do sistema precisos (entre um cluster de servidores) por meio do uso de scripts cron que verificavam o alinhamento de tempo regularmente e os corrigiam quando necessário. Também usamos Ntpd para evitar o desvio do relógio.
Outros dados capturados
Outros dados capturados para cada edição também incluíram (mas não limitados a):
User_id
User_group
Action
Approval_id
Havia também outras tabelas que atendiam aos requisitos internos (incluindo anotações geradas automaticamente para os documentos) - já que parte da edição do perfil foi feita usando dados de bots (construídos usando NER/machine learning/AI), mas com aprovação exigida por um dos a equipe antes que as edições/atualizações pudessem ser publicadas.
Também foi mantido um registro de ações de todas as ações do usuário, para que, no caso de uma auditoria, fosse possível observar as ações de um usuário individual - mesmo quando ele não tivesse permissão para realizar tal ação, ainda era registrado .
Com relação à migração, não vejo isso como um grande problema, pois você pode facilmente preservar as sequências de id na movimentação/descarga/transferência de dados. Talvez o único problema seja se você precisasse mesclar conjuntos de dados. Você sempre pode escrever um script de migração nesse caso - então, de uma perspectiva pessoal, considero essa desvantagem um pouco diminuída.
Pode valer a pena olhar para as estruturas de tabela do Stack Overflow para o explorador de dados (que é razoavelmente sofisticado). Você pode ver a estrutura da tabela aqui:https://data.stackexchange.com/stackoverflow/query /novo , que vem de uma pergunta no meta:Como o SO armazena revisões?
Como um sistema de revisão, o SO funciona bem e a funcionalidade de remarcação/revisão é provavelmente um bom exemplo a ser escolhido.
