¿La mejor manera de administrar el flujo de trabajo update-review-publish?

Question

Administro un catálogo en línea. Actualmente el personal interno lo actualiza manualmente y sus cambios son visibles inmediatamente. Ahora queremos agregar un paso de verificación: Tom hace un cambio, Jerry lo aprueba.

Veo dos caminos, pero ninguno parece elegante.

1. Guarde una segunda 'copia de trabajo' de toda la base de datos.
2. Mantenga un segundo conjunto de tablas "sucias" dentro de la misma base de datos.

Ambos parecen requerir una gran cantidad de código solo para tareas domésticas, así como el doble del trabajo cada vez que cambia la estructura de una mesa.

¿Hay una manera mejor? En caso de que importe, el DBMS es SQL Server, la aplicación web es asp.net.

Editado para añadir:

1. Los dos cambios que he descrito son compatibles hacia atrás tanto con el código existente. Sé que voy a tener que hacer algunos cambios, pero no puedo alterar cada consulta.

2. Creo que mis restricciones clave prohíben simplemente clonar filas y marcarlas como 'pendientes'.

Digamos que Proveedor con el ID del proveedor 99 tiene dos productos. (Los productos pueden pertenecer a un solo SupplierID). El número de teléfono del proveedor ha cambiado, por lo que clono el registro del proveedor, cambio el número de teléfono y lo marcó como 'pendiente'. Pero el nuevo registro no puede tener una ID de 99, por lo que ya no hay forma de conectarlo a sus productos o incluso al registro que pretende reemplazar.

Supongo que podría agregar un identificador no restringido, SupplierPseudoID, pero esto parece tan complicado y propenso a errores como las ideas anteriores.

Answer 1

¿Por qué necesita una copia de las tablas? ¿Por qué no simplemente agrega un campo approved en la tabla?

---

respuesta a la edición:

Si tiene una tabla como

id | name | text | modified | etc 
----------------------------------- 
1 | aaaa | blabla | 20100210 | xxx 
2 | bbbb | yadayada| 20100212 | yyy 
3 | cccc | asdfkad | 20090102 | zzz 

que sólo puede alterarlo para añadir un nuevo campo llamado appoved y crea la clave primaria sea tanto id y modified

id | name | text | modified | etc | approved 
----------------------------------------------- 
1 | aaaa | blabla | 20100210 | xxx | 1 
2 | bbbb | yadayada| 20100212 | yyy | 1 
3 | cccc | asdfkad | 20090102 | zzz | 1 
3 | cccc | qwerklj | 20100219 | zzz | 0 

Crea un opinión de que sólo le trae

id | name | text | modified | etc 
----------------------------------- 
1 | aaaa | blabla | 20100210 | xxx 
2 | bbbb | yadayada| 20100212 | yyy 
3 | cccc | asdfkad | 20090102 | zzz 

definiéndola como algo parecido a SELECT id, name, text, modified, etc FROM catalog WHERE approved = 1;, de esa manera es suficiente con modificar la "mesa" las consultas elegir.Para evitar tener que modificar la inserción deben darle aprobado un valor por defecto de 0 y modificar las consultas de actualización para hacer algo como

INSERT INTO catalog (id, name, text, modified, etc, approved) 
    VALUES (SELECT id, name, text, NOW(), etc, 0) 

, terminaría con algo como

id | name | text | modified | etc | approved 
----------------------------------------------- 
1 | aaaa | blabla | 20100210 | xxx | 1 
2 | bbbb | yadayada| 20100212 | yyy | 1 
3 | cccc | asdfkad | 20090102 | zzz | 1 
3 | cccc | qwerklj | 20100219 | zzz | 0 

y el nuevo bit de la interfaz que va a tener que hacer para "aprobar un campo" tendría que

UPDATE catalog SET approved = 1; 
DELETE FROM catalog WHERE id = @id AND approved = 1 AND MIN(modified); 

lo que resultaría en

id | name | text | modified | etc | approved 
----------------------------------------------- 
1 | aaaa | blabla | 20100210 | xxx | 1 
2 | bbbb | yadayada| 20100212 | yyy | 1 
3 | cccc | qwerklj | 20100219 | zzz | 1 

Este último bit se podría simplificar aún más si realiza un desencadenador o un procedimiento almacenado para hacerlo.

Este es un ejemplo muy vago, se adapta a sus necesidades.

Answer 2

Tendría un campo aprobado y tendría un activador en el campo que limitaría los cambios al estado aprobado que vendrían solo de los usuarios en un rol de aprobador específico (que si no tiene un rol o grupo) escriba algo para sus usuarios que también necesitará para saber quiénes son los usuarios autorizados y los aprobadores. De esta forma, si Sam intenta aprobar su propio cambio, no puede suceder. Probablemente también tenga un mecanismo para verificar que un aprobador que realiza un cambio debe tener su cambio aprobado por otra persona.

Su aplicación también debería cambiar para permitir que los usuarios generales del catálogo solo vean los cambios aprobados a menos que sean la persona que inició el cambio o los aprobadores.

Answer 3

Simplemente versione su tabla importante con estados.

La misma tabla, solo filas adicionales. Agregue un rango de "fecha efectiva" a la tabla.

select * from catalog where item_code = '1234' and status = 'APPROVED' and 
today >= start_date and (today <= end_date or end_date is null) 

Cuando se desea cambiar los datos, copiar la fila, cambiar el estado a "Review" (o lo que sea, sin embargo muchos pasos que tienes).

A continuación, sus revisores pueden ver eso.

Cuando "publica", el actual "APROBADO" se convierte en "ARCHIVADO", end_date = "today", y la fila "REVIEW" se convierte en "ACCEPTED" con null end_date y start_date = "today".

Lo bueno de esto es que es razonablemente trivial "retroceder" rápidamente un cambio si lo desea, y siempre tiene un historial. Más tarde, puede purgar datos ARCHIVADOS antiguos, si así lo desea.

También puede preconfigurar artículos que no se venden (o lo que sea) hasta el primero del mes.