Usando el id secuencial sería más simple ya que probablemente (?) Una clave principal y, por lo tanto, indexada y de acceso más rápido. Dado que tiene user_id , puede confirmar rápidamente las últimas ediciones y las anteriores.
Usando la timestamp también es aplicable, pero es probable que sea una entrada más larga y no sabemos si está indexada, además de la posibilidad de colisiones. Usted señala correctamente que los relojes del sistema pueden cambiar... Mientras que secuencial id no puede.
Dada su actualización:
Como es difícil ver cuáles son sus requisitos exactos, he incluido esto como evidencia de lo que requiere un proyecto en particular para más de 200 000 documentos complejos y millones de revisiones.
A partir de mi propia experiencia (construyendo un sistema de elaboración de perfiles/documentación totalmente auditable) para un equipo interno de más de 60 investigadores a tiempo completo. Terminamos usando un id y una serie de otros campos (incluyendo timestamp ) para proporcionar seguimiento de auditoría y control de versiones completo.
El sistema que construimos tiene más de 200 campos para cada perfil y, por lo tanto, crear una versión de un documento era mucho más complejo que simplemente almacenar un bloque de texto/contenido modificado para cada uno; Sin embargo, cada perfil puede editarse, aprobarse, rechazarse, revertirse, publicarse e incluso exportarse como PDF u otro formato como UN documento.
Lo que terminamos haciendo (después de mucha estrategia/planificación) fue almacenar versiones secuenciales del perfil, pero estaban tecleadas principalmente en un id campo .
Marcas de tiempo
Las marcas de tiempo también se capturaron como una verificación secundaria y nos aseguramos de mantener los relojes del sistema precisos (entre un grupo de servidores) mediante el uso de secuencias de comandos cron que verificaban la alineación de tiempo regularmente y los corregían cuando era necesario. También usamos Ntpd para evitar la desviación del reloj.
Otros datos capturados
Otros datos capturados para cada edición también incluyen (pero no se limitan a):
User_id
User_group
Action
Approval_id
También había otras tablas que cumplían con los requisitos internos (incluidas las anotaciones generadas automáticamente para los documentos), ya que parte de la edición del perfil se realizó con datos de bots (construidos con NER/aprendizaje automático/IA), pero con la aprobación requerida por uno de el equipo antes de que se pudieran publicar ediciones/actualizaciones.
También se mantuvo un registro de acciones de todas las acciones de los usuarios, de modo que, en caso de una auditoría, se pudieran ver las acciones de un usuario individual; incluso cuando no tenían los permisos para realizar dicha acción, todavía se registraba. .
Con respecto a la migración, no lo veo como un gran problema, ya que puede conservar fácilmente las secuencias de identificación al mover/volcar/transferir datos. Quizás el único problema es si necesita fusionar conjuntos de datos. Siempre puede escribir un script de migración en ese caso, por lo que, desde una perspectiva personal, considero que esa desventaja ha disminuido un poco.
Podría valer la pena mirar las estructuras de la tabla Stack Overflow para el explorador de datos (que es razonablemente sofisticado). Puede ver la estructura de la tabla aquí:https://data.stackexchange.com/stackoverflow/query /nuevo , que proviene de una pregunta en meta:¿Cómo almacena SO revisiones?
Como sistema de revisión, SO funciona bien y la funcionalidad de reducción/revisión es probablemente un buen ejemplo para elegir.
