mysql - Manteniendo el historial de cambios de página. Un poco como SO para las revisiones

database version-control

Question

Tengo un sistema CMS que almacena datos en tablas como esta:

Entries Table
+----+-------+------+--------+--------+
| id | title | text | index1 | index2 |
+----+-------+------+--------+--------+
Entries META Table
+----+----------+-------+-------+
| id | entry_id | value | param |
+----+----------+-------+-------+
Files Table
+----+----------+----------+
| id | entry_id | filename |
+----+----------+----------+
Entries-to-Tags Table
+----+----------+--------+
| id | entry_id | tag_id |
+----+----------+--------+
Tags Table
+----+-----+
| id | tag |
+----+-----+

Estoy tratando de implementar un sistema de revisión, un poco como SO. Si solo lo estaba haciendo para la Entries Table , estaba planeando guardar una copia de todos los cambios en esa tabla en una tabla separada. Como tengo que hacerlo para al menos 4 tablas (la tabla TAGS no necesita tener revisiones) esto no parece en absoluto una solución elegante.

¿Cómo lo harían ustedes?

Tenga en cuenta que las Meta Tablas se modelan en EAV (entidad-valor-atributo) .

Gracias de antemano.

Answer 1

Hola, actualmente estoy trabajando para solucionar un problema similar, lo estoy resolviendo dividiendo mis tablas en dos, una mesa de control y una tabla de datos. La tabla de control contendrá una clave primaria y una referencia en la tabla de datos, la tabla de datos contendrá la clave de revisión de incremento automático y la clave primaria de la tabla de control como una clave externa.

tomando su tabla de entradas como ejemplo

Entries Table
+----+-------+------+--------+--------+
| id | title | text | index1 | index2 |
+----+-------+------+--------+--------+

se convierte

entries entries_data
+----+----------+ +----------+----+--------+------+--------+--------+
| id | revision | | revision | id | title | text | index1 | index2 |
+----+----------+ +----------+----+--------+------+--------+--------+

para consultar

select * from entries join entries_data on entries.revision = entries_data.revision;

en lugar de actualizar la tabla entries_data, usa una instrucción insert y luego actualiza la revisión de la tabla de entradas con la nueva revisión de la tabla de entradas.

La ventaja de este sistema es que puede pasar a diferentes revisiones simplemente cambiando la propiedad de revisión dentro de la tabla de entradas. La desventaja es que necesita actualizar sus consultas. Actualmente estoy integrando esto en una capa ORM para que los desarrolladores no se preocupen por escribir SQL de todos modos. Otra idea con la que estoy jugando es que haya una tabla de revisión centralizada que utilicen todas las tablas de datos. Esto le permitiría describir el estado de la base de datos con un solo número de revisión, similar a cómo funcionan los números de revisión de subversión.

Answer 2

Para uno de nuestros proyectos, fuimos de la siguiente manera:

Entries Table
+----+-----------+---------+
| id | date_from | date_to |
+----+--------_--+---------+
EntryProperties Table
+----------+-----------+-------+------+--------+--------+
| entry_id | date_from | title | text | index1 | index2 |
+----------+-----------+-------+------+--------+--------+

Bastante complicado, todavía permite hacer un seguimiento del ciclo de vida completo del objeto. Entonces, para consultar entidades activas íbamos por:

SELECT
entry_id, title, text, index1, index2
FROM
Entities INNER JOIN EntityProperties
ON Entities.id = EntityProperties.entity_id
AND Entities.date_to IS NULL
AND EntityProperties.date_to IS NULL

La única preocupación era por una situación en la que se eliminaba la entidad (por lo que pusimos una fecha_ahí) y luego la restauraba el administrador. Usando el esquema dado, no hay forma de seguir ese tipo de trucos.

La desventaja general de cualquier intento como ese es obvia: tienes que escribir toneladas de TSQL donde los DB no versionados buscarán algo como seleccionar A join B.

Answer 3

Eche un vistazo a esta pregunta: cómo controlar la versión de un registro en una base de datos

¿Por qué no tener una tabla de historial separada para cada tabla (según la respuesta aceptada en la pregunta vinculada)? Eso simplemente tiene una clave primaria compuesta de PK de las tablas originales y el número de revisión. De todos modos, deberá almacenar los datos en algún lugar.