Modelo de base de datos en vivo y en borrador

Question

He estado deliberando sobre la mejor manera de mantener un conjunto de datos "en vivo" y un conjunto de datos en borrador en la base de datos. La versión en vivo se muestra en un sitio web y la versión en borrador se trabaja hasta que esté lista para entrar en funcionamiento. El modelo es relacional y consta de muchas tablas.

Mi método actual es tener 2 bases de datos, una para el borrador y otra para el directo. Cuando promociona los datos para que vivan, SQL simplemente copie los datos del borrador de base de datos a la base de datos en vivo.

Esto está bien, pero un poco lento y parece desordenado. Y frecuentemente SQL tiene que considerar ambos conjuntos de tablas.

Otra forma sería hacer que un indicador en vivo sea parte de la clave de cada tabla, de modo que pueda mantener tanto en vivo como en borrador en la misma tabla y actualice el indicador para que los datos estén activos. - No estoy realmente convencido de esta idea.

• El DBMS es Sybase.

Estaría agradecido si alguien tiene alguna otra sugerencia.

U.M.

Answer 1

tienen una tabla

DataTable 
    DataKey 
    DataMode 
    Data... 

PK es DataKey + DataMode
restricción de comprobación: DataMode IN ('L', 'D') --live o proyecto

inserta por primera vez con DataMode = 'D' --draft
cuando se va en vivo, copiarla en la misma mesa con un INSERT SELECT, establecer DataMode = 'L'
siempre editar el DataMode = 'D', y empujarlo a la DataMode = 'L 'Cuando haya terminado con eso.

cuando se quiere mostrar la lectura de datos en el modo, el uso donde DataKey = @ x = @ Y DataMode modo

No estoy seguro de cómo va a manejar eliminaciones (borrador borrar y empuje que vivir ?) es posible que desee agregar una columna de estado:

DataStatus --'A'ctive 'D'eleted 

hacerlo en una mesa permite el uso común de todos sql para trabajar, ya sea para "L" ive o "D'balsa

Answer 2

creo. este es un candidato principal para citas efectivas. Agregue una fecha de inicio y finalización para cada tabla. Si la fecha actual es En las fechas de inicio y finalización o después de la fecha de inicio y el final es NULL, el registro es en vivo. Cualquier otra cosa no se muestra como en vivo, lo que le permite tener sus datos de Borrador.

Esto permitiría más de un conjunto de datos de borrador si los datos son secuenciales y se debe mantener un historial de valores previos. O si los volúmenes de datos son un problema, tenga un trabajo que se ejecute en momentos de baja carga de trabajo de DB para eliminar cualquier registro con una fecha de finalización menor que la fecha actual.

Answer 3

Dos ideas, dependiendo de las circunstancias.

Si algunos datos permanecen actual cuando una versión Proyecto de rollos, y lo que desea hacer nuevos datos eficaz a la vez, puede tener un número de versión para cada elemento de datos, y una opción de configuración para el número de versión activa actual .Luego, escriba la lógica para que los registros seleccionados tengan Números de versión < = Número de versión actual (ignorando los Números de versión más altos). Esto sería una interrupción baja, y tal vez maneje lo que quiere decir con la necesidad de ambas versiones disponibles.

Si desea intercambiar tablas completas, y puede desconectar cosas (muy) brevemente, cambie el nombre de las tablas. Probablemente sea menos perjudicial que las opciones que describe, y también podría permitir el acceso simultáneo.

Answer 4

Realiza la clave lo que ya se está utilizando, y una columna is_live booleano con defecto a N. Cuando se desea publicar, simplemente actualizar esa columna a Y.

Tener este trabajo le obligará a revisar todas las consultas para que filtren los borradores cuando no se los debe ver, pero le evitarán tener que mantener 2 tablas paralelas con los mismos formatos y todo eso.