Almacenar cambios en los registros

Question

Todo lo que estoy hablando se relaciona con la base de datos relacional, MySQL específica.

Tengo varias tablas en una base de datos y para un número moderado de ellas, voy a querer almacenar un historial de los valores de los registros cuando cambie. He visto esto hecho de un par de maneras diferentes:

1. Una tabla/un campo: básicamente hay una tabla que almacena el historial de toda la tabla que necesitan almacenamiento del historial. Todos los cambios se registran en un campo como tipo de datos de texto.
2. Tabla por tabla/un campo: igual que el anterior, excepto que cada tabla tiene su propia tabla de historial (es decir, proyectos/proyectos, emisión, temas/problemas, etc ...).
3. Tabla por tabla/campo por campo: esto es como lo anterior en cada tabla de cada tabla tiene su propia tabla Histroy, pero también la tabla de historial tiene casi la misma definición que la tabla regular con un adicional de los campos relacionados con el historial adicionales (actualizatetateTime, UpdateUserID, etc...).

¿Cuáles son algunas de las ventajas y desventajas para estos diferentes métodos para almacenar la historia de los registros? ¿Hay otros métodos en los que no he pensado?

Answer 1

Dado que tiene muchas tablas con diferentes cantidades de columnas, el n. ° 1 estaría fuera ya que tendría una tabla masiva con el agregado de todas sus columnas y muchos nulos.

Entre #2 & #3 creo que tiene que tomar una decisión sobre la complejidad de diseño que desea administrar. Mi opinión es que sería más fácil mantener una réplica de archivo exacta para una tabla determinada y almacenar todo el estatal Row (con tiempo modificado). Piense en un caso en el que actualice más de una columna de una fila. En ese caso, n. ° 2 registraría una entrada para el cambio de las columnas por separado, a pesar de que era la misma transacción. Iría W #3 para reducir la complejidad y capturar el estado de la fila de punto en el punto de tiempo.

Answer 2

Realmente quieres leer primero:

http://www.cs.arizona.edu/~rts/tdbbook.pdf

Si desea mantener su historial en una tabla separada (y probablemente lo haga), probablemente desee la opción #3; Tiende a ser más fácil de implementar y más conveniente, el #1 son #2 son bastante feos y "no relacionales".

Answer 3

Hasta cierto punto, depende de cómo pretenda usar esos datos. Si esta es una tabla de auditoría utilizada estrictamente para poder investigar ocasionalmente quién cambió qué y cuándo y ocasionalmente restaura los cambios malos, entonces la opción 2 está bien. Si tiene la intención de mostrar el historial de usuarios en la aplicación o mediante la presentación de informes, use la opción 3. No puedo pensar en ninguna circunstancia en la que use la opción uno, ya que aumenta los lugares donde ocurre el bloqueo.