Estructura de la base de datos para rastrear el historial de cambios

Question

Estoy trabajando en diseños de bases de datos para un sistema de gestión de proyectos como proyecto personal y me he encontrado con un problema.

Quiero implementar un sistema de tickets y quiero que los tickets se vean como tickets in Trac. ¿Qué estructura usaría para replicar este sistema? (No he tenido éxito instalando trac en ninguno de mis sistemas, así que realmente no puedo ver lo que está haciendo)

Nota: no me interesa intentar almacenar o mostrar el ticket en ninguna versión. Solo necesitaría un historial de cambios. No quiero almacenar datos adicionales. Además, he implementado una característica como esta usando una matriz serializada en un campo de texto. No quiero implementar eso como una solución nunca más.

Editar: Estoy buscando solo estructuras de bases de datos. Los disparadores/devoluciones de llamada no son realmente un problema.

Answer 1

he implementado datos de cambio de registro puros utilizando un diseño "delgado":

RecordID Table Column OldValue NewValue 
-------- ----- ------ -------- -------- 

puede que no desee utilizar "Tabla" y "Columna", sino más bien "objeto" y "Propiedad ", y así sucesivamente, dependiendo de su diseño.

Esto tiene la ventaja de la flexibilidad y simplicidad, a costa de la velocidad de consulta: los índices agrupados en las columnas "Tabla" y "Columna" pueden acelerar las consultas y los filtros. Pero si va a ver el registro de cambios en línea con frecuencia a nivel de tabla o de objeto, es posible que desee diseñar algo más plano.

EDIT: varias personas han señalado con razón que con esta solución no se podía juntar un conjunto de cambios. Olvidé esto en la tabla anterior: la implementación con la que trabajé también tenía una tabla de "Transacción" con fecha y hora, usuario y otra información, y una columna "ID de transacción", por lo que el diseño sería así:

CHANGE LOG TABLE: 
RecordID Table Column OldValue NewValue TransactionID 
-------- ----- ------ -------- -------- ------------- 

TRANSACTION LOG TABLE: 
TransactionID UserID TransactionDate 
------------- ------ --------------- 

Answer 2

Yo diría crear algún tipo de clase de escucha de eventos que haga ping cada vez que ocurra algo dentro de su sistema & coloca una descripción del evento en una base de datos.

Debe almacenar información básica de quién/qué/dónde/cuándo/qué.

clasificando a través de esa tabla de eventos de proyecto debería obtener la información que desea.

Answer 3

¿Estás buscando un mecanismo de base de datos como este?

CREATE OR REPLACE TRIGGER history$yourTable 
     BEFORE UPDATE ON yourTable 
     FOR EACH ROW 
     BEGIN 
      INSERT INTO 
       history 
      VALUES 
       (
       :old.field1, 
       :old.field2, 
       :old.field3, 
       :old.field4, 
       :old.field5, 
       :old.field6 
       ); 
     END; 
    /
    SHOW ERRORS TRIGGER history$yourTable 

Answer 4

Una posible solución es almacenar una copia del ticket en una tabla de historial con el usuario que realizó el cambio.

Sin embargo, esto almacenará una gran cantidad de datos adicionales y requerirá mucho procesamiento para crear la vista que muestra Trac.

Answer 5

En cuanto a no almacenar una gran cantidad de datos adicionales, no puedo pensar en ninguna buena manera de hacerlo. Tienes que almacenar cada revisión para ver los cambios.

He aquí una solución que he visto, aunque no estoy seguro de si es la mejor. Tener una clave principal, digamos id que apunta a una revisión en particular. también tienen campos ticket_number y revision_date.ticket_number no cambia cuando revisa un ticket, pero id y revision_date lo hacen. Luego, dependiendo del contexto, puede obtener una revisión particular o la última revisión de un boleto en particular, usando groupwise max.

Answer 6

Hice algo como esto. Tengo una tabla llamada LoggableEntity que contiene: ID (PK).

Luego tengo la tabla EntityLog que contiene información sobre los cambios realizados en una logunctionentity (registro): ID (PK), EntityID (FK a LoggableEntity.ID), ChangedBy (nombre de usuario que realizó un cambio), ChangedAt (smalldatetime cuando el cambio ocurrido), Tipo (enumerar: Crear, Eliminar, Actualizar), Detalles (campo memo que contiene lo que ha cambiado - podría ser un XML con detalles serializados).

Ahora cada tabla (entidad) de la que quiero hacer un seguimiento se "deriva" de la tabla LoggableEntity, lo que significa que, por ejemplo, el Cliente tiene una tabla FK a LoggableEntity.

Ahora mi código DAL se encarga de rellenar la tabla EntityLog cada vez que se realiza un cambio en un registro de cliente. Cada vez que ve que esa clase de entidad es una entidad de almacenamiento, agrega un nuevo registro de cambio en la tabla de registro de la entidad.

Así que aquí es mi estructura de la tabla:

+------------------+   +------------------+ 
| LoggableEntity |   | EntityLog  | 
| ---------------- |   | ---------------- | 
| (PK) ID   | <--+  | (PK) ID   | 
+------------------+ +----- | (FK) LoggableID | 
     ^     |  ...   | 
     |      +------------------+ 
+------------------+ 
| Customer   | 
| ---------------- | 
| (PK) ID   | 
| (FK) LoggableID | 
|  ...   | 
+------------------+