sql >> Base de Datos >  >> RDS >> Mysql

Gestión eficaz de los cambios de datos.

Parece que estás intentando implementar una Temporal Database . El soporte temporal fue una de las principales adiciones al estándar ANSI/ISO SQL:2011. MySQL (como la mayoría de RDBMS) va a la zaga del estándar. Piense en Temporal Database como el DBMS equivalente a CVS/SVN/Git.

Por el contrario, la base de datos tradicional que usamos sin características temporales se puede llamar Base de datos actual .

En una base de datos actual , si intenta implementar soporte temporal, puede fallar de muchas maneras con diferentes enfoques:

  • El enfoque de una mesa. Cuando necesite hacer modificaciones, haga UPDATEs en sus registros originales, y a menos que tenga algún tipo de lógica de activación/auditoría de cosecha propia, el rastro del historial está ausente. Incluso si tiene un registro de cambios/auditoría, tendría que hacer algunas excavaciones feas para reconstruir el historial de cambios.

  • El enfoque de dos mesas. En lugar de realizar modificaciones en el lugar, divide sus datos en dos tablas, una con los registros base/originales (por ejemplo, reserva) y otra tabla para sus cambios/modificaciones/deltas. Entonces, al menos conservará sus datos originales, pero nuevamente debe escribir una lógica compleja para ver los datos originales con modificaciones en capas. Se pone aún peor si solo quieres algo de las modificaciones aplicadas.

  • El enfoque de la tabla resultante precalculada . Mantienes 3 o más tablas:los registros base, las modificaciones, y también una tabla que intenta tener siempre la resultante (mantiene actualizada la base + modificaciones). Buena suerte al escribir los disparadores y los procedimientos para hacer este cálculo siempre que haga INSERTs , y el cielo te ayude si una UPDATE o DELETE se necesita La configuración es frágil y podría perder la sincronización, como interbloqueos y retrocesos. Si no hace esto dentro de la base de datos con disparadores/procedimientos, podría intentar implementar el cálculo resultante en el código de la aplicación, pero tenga suerte en eso, y podría ponerse feo con los consumidores de subprocesos múltiples. Y aún así, no tiene fácil acceso a las resultantes con solo algunas modificaciones aplicadas.

Conclusión: Si no está limitado a MySQL, realmente debería considerar usar una base de datos que tenga soporte temporal incorporado. De lo contrario, volverá a implementar la rueda.