Bien, esto es una reescritura. Lo que me perdí cuando respondí por primera vez es que la aplicación está almacenando su Historial en la tabla principal. Ahora entiendo por qué @NickCraver se disculpa tanto por el código.
Bueno, lo primero que debe hacer es cazar a los perpetradores de este diseño y asegurarse de que nunca lo vuelvan a hacer. Almacenar el historial de esta manera no escala, hace que las consultas normales (no históricas) sean más complicadas y sabotea la integridad relacional. Obviamente, hay escenarios en los que nada de eso importa, y quizás su sitio sea uno de ellos, pero en general es una implementación muy mala.
La mejor forma de hacerlo es Oracle 11g Total Recall . Es una solución elegante, con una implementación completamente invisible y eficiente y, según los estándares de otros extras con cargo de Oracle, a un precio bastante razonable.
Pero si Total Recall está fuera de discusión y realmente debe hacerlo, no permita actualizaciones . Un cambio en un registro de CONTACTO existente debe ser una inserción. Para que esto funcione, es posible que deba crear una vista con un disparador INSTEAD OF. Todavía es asqueroso, pero no tanto como lo que tienes ahora.
A partir de Oracle 11.2.0.4, Total Recall pasó a llamarse Flashback Archive y se incluye como parte de la licencia Enterprise (aunque sin las tablas de diario comprimidas, a menos que compremos la opción Advanced Compress).
Esta generosidad de Oracle debería hacer que FDA sea la forma normal de almacenar el historial:es eficiente, es eficaz, es un Oracle integrado con sintaxis estándar para admitir consultas históricas. Por desgracia, espero ver implementaciones a medio cocinar con activadores intermitentes, claves primarias rotas y un rendimiento horrible durante muchos años. Porque llevar un diario parece ser una de esas distracciones que encantan a los desarrolladores, a pesar de que es una plomería de bajo nivel que es en gran medida irrelevante para el 99,99% de todas las operaciones comerciales.
