La primera pregunta debería ser:¿qué harías con esos datos? Si no tiene un requisito comercial claro, no lo haga.
Hice algo similar y después de 3 años de ejecución hay alrededor del 20% de "datos válidos" y el resto son "versiones anteriores". Y son 10 millones + 40 millones de registros. En los últimos tres años, tuvimos 2 (dos) solicitudes para investigar el historial de cambios y en ambas ocasiones las solicitudes fueron tontas:registramos la marca de tiempo del cambio de registro y se nos pidió que verificáramos si las personas trabajaron horas extra (después de las 5:00 p. m.).
Ahora, estamos atascados con una base de datos de gran tamaño que contiene el 80 % de los datos que nadie necesita.
EDITAR:
Ya que pidió posibles soluciones, describiré lo que hicimos. Es un poco diferente a la solución que está considerando.
- Todas las tablas tienen una clave principal sustituta.
- Todas las claves principales se generan a partir de una sola secuencia. Esto funciona bien porque Oracle puede generar y almacenar números en caché, por lo que aquí no hay problemas de rendimiento. Usamos ORM y queríamos que cada objeto en la memoria (y el registro correspondiente en la base de datos) tuviera un identificador único
- Usamos ORM y la información de mapeo entre la tabla de la base de datos y la clase está en forma de atributos.
Registramos todos los cambios en una sola tabla de archivo con las siguientes columnas:
- id (clave principal sustituta)
- marca de tiempo
- tabla original
- id del registro original
- identificación de usuario
- tipo de transacción (insertar, actualizar, eliminar)
- registrar datos como campo varchar2
- Estos son datos reales en forma de pares de nombre de campo/valor.
La cosa funciona de esta manera:
- ORM tiene comandos de inserción/actualización y eliminación.
- creamos una clase base para todos nuestros objetos comerciales que anula los comandos de inserción/actualización y eliminación
- los comandos insertar/actualizar/eliminar crean una cadena en forma de pares de nombre de campo/valor mediante la reflexión. El código busca información de asignación y lee el nombre del campo, el valor asociado y el tipo de campo. Luego creamos algo similar a JSON (agregamos algunas modificaciones). Cuando se crea una cadena que representa el estado actual del objeto, se inserta en la tabla de archivo.
- cuando un objeto nuevo o actualizado se guarda en la tabla de la base de datos, se guarda en su tabla de destino y, al mismo tiempo, insertamos un registro con el valor actual en la tabla de archivo.
- cuando se elimina el objeto, lo eliminamos de su tabla de destino y, al mismo tiempo, insertamos un registro en la tabla de archivo que tiene el tipo de transacción ="ELIMINAR"
Ventaja:
- no tenemos tablas de archivo para cada tabla en la base de datos. Tampoco tenemos que preocuparnos por actualizar la tabla de archivo cuando cambia el esquema.
- el archivo completo está separado de los "datos actuales", por lo que el archivo no impone ningún impacto en el rendimiento de la base de datos. Lo colocamos en un tablespace separado en un disco separado y funciona bien.
- creamos 2 formularios para ver el archivo:
- visor general que puede enumerar la tabla de archivo según el filtro en la tabla de archivo. Filtre los datos que el usuario puede ingresar en el formulario (período de tiempo, usuario, ...). Mostramos cada registro en el formulario nombre/valor del campo y cada cambio está codificado por colores. Los usuarios pueden ver todas las versiones de cada registro y pueden ver quién y cuándo realizó cambios.
- visor de facturas:este era complejo, pero creamos un formulario que muestra la factura de forma muy similar al formulario de entrada de facturas original, pero con algunos botones adicionales que pueden mostrar diferentes generaciones. Se necesitó un esfuerzo considerable para crear este formulario. El formulario se usó varias veces y luego se olvidó porque no se necesitaba en el flujo de trabajo actual.
- El código para crear registros de archivo se encuentra en una única clase de C#. No hay necesidad de activadores en cada tabla de la base de datos.
- el rendimiento es muy bueno. En las horas pico, el sistema es utilizado por alrededor de 700 a 800 usuarios. Esta es la aplicación ASP.Net. Tanto ASP.Net como Oracle se ejecutan en un XEON dual con 8 Gb de RAM.
Contras:
- el formato de archivo de tabla única es más difícil de leer que la solución donde hay una tabla de archivo para cada una de las tablas de datos.
- la búsqueda en el campo sin identificación en la tabla de archivo es difícil:solo podemos usar
LIKEoperador en cadena.
Entonces, de nuevo, verifique los requisitos en el archivo . No es una tarea trivial, pero las ganancias y el uso pueden ser mínimos.
