Diseño de Db para aprobación de actualización de datos

Question

Estoy trabajando en un proyecto en el que necesitamos que los datos ingresados ​​o actualizados por algunos usuarios pasen por un estado pendiente antes de ser agregados a 'datos en vivo'.

Mientras prepara los datos, el usuario puede guardar registros incompletos. Aunque los datos están en estado pendiente, no queremos que los datos afecten a las reglas impuestas a los usuarios que editan los datos en vivo, p. un usuario que trabaja en los datos en tiempo real no debe ejecutar un contraint único al ingresar los mismos datos que ya están en estado pendiente.

Imagino que los conjuntos de actualizaciones de datos se agruparán en una "presentación de datos" y los datos se revalidarán y corregirán/rechazarán/aprobarán cuando alguien controle la calidad del envío.

He pensado en dos escenarios en lo que respecta al almacenamiento de los datos:

1) Mantener los datos de estado pendientes en la misma mesa que los datos en tiempo real, pero la adición de una bandera para indicar su estado. Pude ver problemas aquí al tener que eliminar restricciones o hacer que los campos obligatorios se puedan anular para admitir los datos de estado 'incompletos'. Luego está el problema con cómo manejar la actualización de datos existentes, tendría que agregar una nueva fila para una actualización y vincularla a la fila 'en vivo' existente. Esto me parece un poco desordenado.

2) Agregue nuevas tablas que reflejen las tablas en vivo y almacene los datos hasta que se aprueben. Esto me permitiría mantener el control total sobre las mesas en vivo existentes, mientras que las tablas 'pendientes' pueden ser abusadas con lo que el usuario sienta que quiere poner ahí. La desventaja de esto es que terminaré con muchas tablas adicionales/SP en el db. Otro tema en el que estaba pensando era cómo podría un usuario vincular dos registros, por lo que el registro vinculado podría ser un registro en la tabla activa o uno en la tabla pendiente, pero supongo que en esta situación siempre podría tomar una copia del registro vinculado y tratarlo como una actualización?

Ninguna de las dos soluciones parece perfecta, pero la segunda me parece la mejor opción: ¿existe una tercera solución?

Answer 1

Su opción 2 parece la mejor idea. Si desea utilizar la integridad referencial y todas las cosas agradables que obtiene con un SGBD, no puede tener los datos pendientes en la misma tabla.Pero no hay necesidad de que existan datos no estructurados, los datos pendientes aún están estructurados y, presumiblemente, usted desea que el DB haga su parte en la aplicación de las reglas incluso en estos datos. Incluso si no lo hizo, los datos pendientes encajan bien en una estructura de tabla estándar.

Un conjunto separado de tablas suena la respuesta correcta. Puede traer la clave principal de la fila que se cambia a la tabla pendiente para que sepa qué elemento se está editando, o qué elemento se está vinculando.

No conozco su situación exactamente, así que esto podría no ser apropiado, pero una idea sería tener una tabla separada para almacenar el lote de ediciones que se están realizando, porque entonces puede controlar la calidad de un lote, o enviar un lote para vivir Cada tabla pendiente podría tener una clave de lote para que sepa de qué lote forma parte. Deberá encontrar una forma de controlar múltiples ediciones pendientes en las mismas filas (si lo desea) pero eso no parece un problema demasiado complicado de resolver.

No estoy seguro de si esto encaja, pero podría valer la pena examinar las herramientas de "Master Data Management", como los servicios de datos maestros de SQL Server.

Answer 2

'Unit of work' es un buen nombre para 'envío de datos'.

Puede serializarlo en un lugar diferente, como la base de datos orientada a documentos (no relacional), y solo guardar en DB relacional en la aprobación.

Depende de la cantidad de restricciones de datos en vivo que aún deban aplicarse a los datos no aprobados.

Answer 3

Creo que la segunda opción es mejor. Para gestionar esto, puede usar View que contendrá ambas tablas y podrá trabajar con esta estructura a través de view.

---

Otro buen método es utilizar la columna XML en una tabla separada para almacenar los datos necesarios (a causa de la cantidad/nombres desconocidos de columnas). Puede crear solo una tabla con la columna de anuncios XML. "Tipo" sí determina con qué tabla está relacionado este documento.

Answer 4

Primer scenerio parece ser bueno. Agregar columna de estado en la tabla. No es necesario eliminar la restricción anulable. Solo agregue una función para verificar los campos requeridos según indicador como If If flag is 1 (incomplete) Null se permite de lo contrario No permitido. con respecto a la segunda duda, ¿desea agregar los datos o actualizar toda la información?