Estrategia de control de versión genérica para seleccionar datos de tabla dentro de una base de datos muy normalizada

Question

Lo siento por el título largo aliento, pero el requisito/problema es bastante específico.

Con referencia a la siguiente estructura de muestra (pero muy simplificada) (en psuedo SQL), espero poder explicarlo un poco mejor.

TABLE StructureName { 
    Id GUID PK, 
    Name varchar(50) NOT NULL 
} 

TABLE Structure { 
    Id GUID PK, 
    ParentId GUID,     -- FK to Structure 
    NameId GUID NOT NULL   -- FK to StructureName 
} 

TABLE Something { 
    Id GUID PK, 
    RootStructureId GUID NOT NULL -- FK to Structure 
} 

Como se puede ver, la estructura es una estructura simple árbol (no está preocupado acerca de la adquisición de los niños para el problema). StructureName es una simplificación de un sistema de traducción. Finalmente, 'Algo' es simplemente algo que hace referencia a la estructura raíz del árbol.

Esta es solo una de las muchas tablas que se deben versionar, pero esta es un buen ejemplo para la mayoría de los casos.

Existe un requisito para la versión de cualquier cambio en el nombre y/o el 'diseño' del árbol de la tabla de Estructura. Las versiones anteriores siempre deben estar disponibles.

Parece que hay algunas posibilidades para abordar este problema, como copiar toda la estructura, pero la mayoría de los enfoques hace que uno 'pierda' la integridad referencial. Por ejemplo, si uno siguió este enfoque, uno tendría que hacer un duplicado del registro 'Something', dado que la estructura raíz será un nuevo registro y tendrá una nueva ID.

Otras vías de posibles soluciones están investigando cómo Wiki maneja esto o van mucho más allá y cómo funcionan los sistemas de control de versiones adecuados.

Actualmente, me siento un poco despistado de cómo proceder en esto de una manera genérica.

Cualquier idea será muy apreciada.

Gracias

leppie

Answer 1

Algunas ideas rápidas:

copia completa: crear una copia de la estructura, pero por cada mesa de agregar una columna a la version_id PK y todas FKs; por lo tanto, puede crear copias de los datos de vida con integridad referencial completa.

• Pro: fácil de consultar el historial
• con: gran cantidad de (datos redundantes copiados)

Cambio copia: única copia del material que en realidad cambia, junto con valid_from/valid_to datos.

• Pro: baja volum datos copiados
• con: difícil de consultar, porque uno tiene que unirse en intervalos

Variación: Esto se aplica a ambos esquemas. En lugar de crear una copia de la estructura, puede conservar el registro actual en la misma tabla que las versiones anteriores, pero etiquetarlo como actual.

• Pro: menor número de mesas, más fácil de mezcla de la historia y la información actual
• con: funcionamiento normal funciona en tablas mucho más grandes, lo que provocará un impacto en el rendimiento

registro de auditoría: Dependiendo de sus requisitos reales, bastará con crear una pista de auditoría como esta:

id, timestamp, changed_table, changed_column, old_value, new_value, changed_by 

Es posible extender el proceso a una estructura de tabla completa:

transaction, table_change, changed_column 

• Pro: genérico, por lo tanto, fácil de implementar para un gran número de mesas
• con: si usted necesita para reconstruir el estado de un conjunto de registros en un momento dado, la consulta se convertirá en una pesadilla

Escribí a blog about various approaches to versioning, pero tenga cuidado: está en alemán.

Answer 2

La gente de almacenamiento de datos tienen varios algoritmos para "lentamente cambiantes dimensiones".

Los algoritmos más sofisticados proporcionan rangos de datos alrededor de un valor de dimensión para indicar cuándo es válido.

Dependiendo de sus requisitos de control de versiones, podría hacer una de estas cosas, extraída de The Data Warehousing Toolkit de Kimball.

1. Asigne un número de versión a las filas de la tabla de estructura. Esto significa que debe razonar para recopilar una estructura completa. Incluye el número de versión seleccionado unido con filas que no se han modificado en una versión anterior.

2. Asigne un rango de fechas o de versión a las filas de la tabla de estructura. Esto significa que algunas filas tienen fechas de inicio y finalización; algunas filas tendrán fechas de finalización en alguna época en el futuro imposible. O bien, si usa números de versión, tendrá un par de inicio-final o un par de inicio-infinito que indica que esta fila aún está actualizada. A continuación, puede consultar trivialmente las filas que son válidas "hoy" o aplicar a la versión solicitada.

3. Clonar la estructura para cada versión. Esto es desagradable porque la operación de clonación es costosa. Sin embargo, las consultas son triviales porque toda la estructura está disponible con un único número de versión coherente.