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

Perdón por el título sin aliento, pero el requisito / problema es bastante específico.

Con reference 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, Structure es una estructura de tree simple (no está preocupado por orderar el problema a los niños). StructureName es una simplificación de un sistema de traducción. Finalmente, 'Algo' es simplemente algo que hace reference a la estructura raíz del tree.

Esta es solo una de las muchas tablas que necesitan ser versionadas, 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 'layout' del tree de la tabla de Estructura. Las versiones anteriores siempre deben estar disponibles.

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

Otras vías de posibles soluciones son investigar cómo Wiki maneja esto o ir mucho más allá y observar cómo funcionan los sistemas adecuados de control de versiones.

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

Cualquier idea será muy apreciada.

Gracias

Leppie

Algunas ideas rápidas:

Copia completa: cree una copy de la estructura, pero para cada tabla agregue una columna version_id al PK y a todos los FK; por lo tanto, puede crear copys de los datos de vida con integridad referencel completa.

  • pro: fácil consultar la historia
  • con: gran cantidad de (datos networkingundantes copydos)

Cambiar copy: solo copy las cosas que realmente cambian, junto con los datos valid_from / valid_to .

  • pro: baja volum de datos copydos
  • con: difícil de consultar, porque uno tiene que join en intervalos

Variación: Esto se aplica a ambos esquemas. En lugar de crear una copy de la estructura, puede mantener el logging actual en la misma tabla que las versiones anteriores, pero labelrlo como actual.

  • pro: menor cantidad de tablas, mezcla más fácil de historial e información actual
  • con: operación normal opera en tablas mucho más grandes, lo que causará un impacto en el performance

Registro de auditoría: Dependiendo de sus requisitos reales, bastará con crear un seguimiento de auditoría como este:

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

Puede ampliar eso 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 tablas
  • con: si necesita rebuild el estado de un set de loggings en un momento dado, la consulta se convertirá en una pesadilla

Escribí un blog sobre varios enfoques para el control de versiones , pero tenga cuidado: está en alemán.

La gente de almacenamiento de datos tiene varios algorithms para "dimensiones que cambian lentamente".

Los algorithms más sofisticados proporcionan ranges de datos alnetworkingedor de un valor de dimensión para indicar cuándo es válido.

Dependiendo de los requisitos de control de versiones, puede hacer una de estas cosas, extraídas 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 recostackr 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 range de dates o un range de versión a las filas de la tabla de estructura. Esto significa que algunas filas tienen dates de inicio y finalización; algunas filas tendrán dates de finalización en alguna época en el futuro imposible. O bien, si usa numbers 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. Clona 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.