Diseño de instantáneas en una base de datos transaccional junto con versiones de datos de referencia

Question

Descargo de responsabilidad: he leído todo lo que puedo leer sobre el tema de las instantáneas y las versiones tanto en Stack Overflow como en Internet. Mi requisito no es el seguimiento de las versión para la pista de auditoría o las instantáneas a nivel de base de datos. He pasado más de 1 semana para investigar por mi cuenta y pensar en las posibles opciones. Lo siento, podría haber perdido algunos enlaces: si la solución a mi problema ya está discutida en algún otro hilo, por favor, indíqueme allí.

Es un poco largo; Por favor, tenga paciencia conmigo.

Aquí está la situación: estamos tratando de crear un diseño genérico para almacenar instantáneas de los datos transaccionales en nuestra base de datos transaccional y también para mantener un historial de revisión de datos de referencia.

Como parte del proceso de negocio, un usuario puede presionar un botón para publicar cierto objeto. A los efectos de la ilustración, digamos que el usuario puede publicar una propuesta del proveedor antes de que comience la negociación. Luego, en diferentes puntos en el tiempo a través del proceso de negociación, el usuario puede publicar los datos de la propuesta. La propuesta contiene un presupuesto, objetivos de ventas y muchos otros artículos. Cuando una propuesta está instantánea, todas las entidades vinculadas tienen que ser instantáneas. Finalmente, después de la negociación, se firma un contrato. En este punto, se debe crear una instantánea completa del contrato. No todas las entidades en el contrato están en la propuesta: hay muchas entidades superpuestas, pero hay entidades únicas adjuntas a la propuesta y el contrato.

Tenemos que mantener disponibles estas versiones publicadas como las últimas versiones activas disponibles. Las versiones publicadas están disponibles en un sitio web para ser referenciados por ambos proveedores y también el equipo de gestión. No todas las versiones publicadas están disponibles en el sitio web, pero la última propuesta publicada y el último contrato publicado siempre están disponibles en el sitio web. Este sitio web también debe estar poblado de la misma base de datos.

Además, un usuario financiero puede decidir instalar solo el presupuesto solo y un gerente de ventas puede instalar los objetivos de ventas. Por lo tanto, las instantáneas están disponibles en múltiples granularidades.

También tenemos el requisito de rastrear versiones de los datos maestros. Es un requisito comercial para rastrear todos los cambios en las columnas de datos maestros clave a lo largo del tiempo. Por ejemplo, tenemos información de región asociada con los objetivos de ventas. El nombre de la región puede cambiar y queremos rastrear estos cambios. Supongamos que al momento de la propuesta, el nombre de la región es R1 y se crea una instantánea. Luego, el nombre de la región cambia a R2 y luego se crean otras 2 instantáneas. Queremos poder vincular los objetivos de ventas con el nombre de la región correcto en esos puntos en el tiempo, no necesariamente al último nombre de la región.

Tenemos cierta flexibilidad en el modelado, ya que tenemos una DB de transacción y una DB de almacén de datos y podemos decidir almacenar parte de esta información en la transacción DB o en la DB del almacén de datos.

Aquí está nuestro diseño. Tenemos una tabla de publicación que captura información básica sobre los datos publicados: quién publicó y la fecha, la razón y el tipo de objeto publicado (propuesta o presupuesto o objetivos de ventas).

Almacenamos las instantáneas en la misma tabla que los datos originales. Por lo tanto, las instantáneas de propuestas se almacenarían con propuestas en vivo en la tabla de propuestas. Tenemos una columna llamada ID de publicación en cada tabla que debe publicarse. Esta columna es un FK para la tabla de publicación. Si la ID de publicación es nula, ese registro es la versión activa.

Me di cuenta de que la publicación es muy larga. Por lo tanto, en lugar de enumerar los detalles del escenario, pensé en resumir rápidamente las consideraciones de diseño en un mapa mental.

Ahora hay 2 soluciones a las que nos estamos inclinando: ambas almacenarían una instantánea de todos los datos, ya sea que haya cambiado o no. Mantener solo el delta mientras mantiene intactas las estructuras de la tabla requeriría un procedimiento almacenado muy complejo que debe ejecutarse en cada inserción/actualización de cualquiera de los objeto instantáneo. No quiero seguir esta ruta, ya que esto tomaría más tiempo y los volúmenes no son tan grandes de todos modos.

Solución 1: Cada vez, se publica un objeto (como propuesta o presupuesto), poblaríamos un árbol XML y persistiríamos en la base de datos. Solo la última versión debe estar disponible en el sitio web y rara vez se necesitan versiones antiguas. Dado esto, ¿me encontraría con un gran problema de rendimiento debido al uso de XML? Usamos SQL Server. Los volúmenes de datos no son enormes.

Solución 2: Todas las tablas de transacción tendrían una identificación de publicación y los datos de referencia tendrían fechas de inicio y finalización. Cada vez que se publica un objeto, hacíamos una copia de todos los registros de transacciones y poníamos la identificación de publicación allí y copiamos todos los registros de datos de referencia y poníamos una fecha de instantánea como la fecha de finalización. Esto nos permitiría tener versiones normales para datos de referencia fuera del proceso de publicación.

Necesitaría opiniones de mentes experimentadas aquí sobre los inconvenientes de estos 2 enfoques y si hay otro escenario mejor.

Answer 1

Mi enfoque sería optar por la solución 2. Tomar sus consideraciones de diseño en orden:

1. Generaría una copia de todo en la instantánea. Si almacena solo el cambio, se da el problema de los detalles de instantáneas del proceso para obtener la instantánea deseada de los cambios. Inicialmente, esto no es un problema, pero a medida que cambien los esquemas, los programas y los procesos, deberá mantener detalles sobre cómo retener la instantánea deseada de un proceso que ha cambiado. Factible, pero potencialmente frágil.

2. Iraba por una opción que no se menciona en su diagrama, aunque esbozado en su descripción de la solución 2. Esto está utilizando un esquema muy similar al de la transacción DB, pero se extiende para incluir la información específica de las instantáneas. Usted menciona la ID de publicación como clave extranjera y data de los datos de referencia. Es posible que necesite información adicional como fechas, relacionadas con los datos de la transacción.

3. El mismo esquema no funcionará: ha señalado (ID de publicación) que el mismo esquema no es adecuado. Nada en lo que publique sugiere que necesita adoptar un esquema diferente optimizado para la lectura. Incluso si esto demuestra ser requerido, es algo que se puede incorporar en una etapa posterior, con el esquema extendido actual como punto de partida. No tengo mucha experiencia con los árboles XML, pero le preguntaría "¿por qué introducir otra tecnología cuando tiene alternativas que pueden utilizar su infraestructura existente?" Cualquier ventaja que perciba de este enfoque tendría que ser muy significativa para que Warrent deseche la ventaja del apalancamiento de su arquitectura existente. Consideraciones similares se aplican a un DB denormalizado. ¿Por qué ir allí hasta que haya una necesidad demostrada de hacerlo?

4. Nuevamente, adoptaría el enfoque de rastrear versiones y instantáneas. Usted brinda un beneficio principal de este enfoque en su solución 2. Agregaría la instantánea de los datos de referencia como parte del proceso de instantánea, en lugar del proceso de versiones. (Es decir, cuando se tome una instantánea, asegúrese de que las tablas de referencia apropiadas formen parte de la instantánea). Parece a partir de su descripción que tiene dos requisitos diferentes que utilizan los mismos datos: la instantánea y el versiones. Parece haber poca dependencia entre ellos, por lo que debe mantenerlos lo más independientes posible: falta de acoplamiento.

5. Usted menciona potencialmente el uso del almacén de datos como almacenamiento, aunque no se menciona específicamente en sus soluciones. Si sus volúmenes son, como usted sugiere, bajo, entonces hubiera pensado que una base de datos separada era adecuada. Da la impresión de que los volúmenes de datos y usuarios para las instantáneas son bajas, por lo que no parece haber un caso prima facie para usar el almacén de datos. Al mismo tiempo, el almacén tiene algunos mecanismos para almacenar exactamente este tipo de datos históricos, que se utilizarán para la lectura y el análisis.

Lamento no haber respondido directamente a sus preguntas aquí, pero espero que esto proporcione algunos consejos y otra opinión sobre su situación declarada.