¿Cómo lidiar con los datos de base de datos viejos y obsoletos de un sistema de larga ejecución?

Question

¿Cuáles son las posibilidades de un programador para manejar datos que rara vez se utilizan pero que no se pueden eliminar simplemente porque al menos los informes todavía lo requieren?

Algunos ejemplos que estoy pensando:

• tipos de financiación Discontinuos de años anteriores de una universidad
• monedas no utilizadas (por ejemplo, lira italiana)
• Los nombres de los países desaparecidos (por ejemplo, Austria-Hungría, URSS)

Algunas soluciones parciales son indicadores de actividad, períodos de actividad, prioridades de visualización, pero cada uno de ellos significa una decisión caso por caso y es difícil saber wh en tipos de entidades necesita este manejo especial.

Puede haber un patrón de diseño para este problema.

Conclusiones: (basado en las respuestas hasta ahora)

• Si los datos de edad hace difícil el trabajo diario en una enorme base de datos, la partición sería útil. La descripción de Oracle sobre este tema es here.

• Desde el punto de vista del diseñador, la taxonomía de Slowly changing dimension proporciona algunos antecedentes.

Answer 1

Con los datos antiguos no utilizados en la mayoría de las consultas, la mejor solución es dividir las tablas por la clave que diferencia los datos obsoletos de los actuales (como date, currency_id o cosas por el estilo). A continuación, puede colocar los datos obsoletos en tablas, bases de datos o incluso servidores (según la configuración que tenga en ejecución).

La desventaja de esto es que su aplicación debe conocer la partición para saber dónde encontrar los datos (aunque hay abstracciones que ayudan a lidiar con la fragmentación y la partición).

Answer 2

Una solución podría ser (registros suponiendo que hacen referencia a datos obsoletos son los más antiguos): archivo esos registros y eliminar los datos de referencia de edad.

Answer 3

En varios casos, he duplicado los datos antiguos y el programa anterior con el conjunto de permisos de solo lectura apropiado. Por lo tanto, los usuarios tienen la capacidad de ver los datos antiguos y hacer informes utilizando el programa anterior. Entonces puede avanzar el programa moderno como lo crea conveniente, eliminar columnas o tablas, migrar algunos datos, etc.

Answer 4

Realmente tiene que manejarlo caso por caso, ya que son las reglas comerciales las que definen cuándo un el registro obsoleto es relevante o no. Por ejemplo, en algunos resúmenes históricos tendría sentido incluir ventas a la URSS, en otros casos lo dejaría fuera.

Un patrón general sería tener un campo de tiempo de datos "relevante desde/hacia" en los registros. En ese caso, los informes históricos pueden incluir los tipos que son relevantes para el período. (Una solución más simple sería una bandera booleana "obsoleta" en los registros, pero dado que esto no indica cuándo era relevante, no será tan útil para el informe histórico.)

Answer 5

Además de lo que dijo Eran sobre la parición, podría automatizar parcialmente el proceso de decidir qué incluir en la parición archivada al tener una columna LastModified o similar. Luego, simplemente con la partición basada en LastModified < -1y más o menos, el sistema debería aprender sobre los datos obsoletos.

Answer 6

Este es el problema estándar de Dimensión que cambia lentamente. Tienes SCD con estado y/o rango de fechas.

"cada uno de ellos significa un caso por caso decisión y es difícil saber qué tipos de entidades necesitan este especial manipulación"

Sip. Lo siento por eso. Tienes que analizar tus datos y pensar. No es una forma fácil de entender la parte de pensamiento de esto.

Answer 7

Para cualquier entidad que pueda tener una vida útil limitada, simplemente agregue un componente de tiempo en su definición. P.ej. su lira italiana puede ser modelado como:

CREATE TABLE Currency (CurrencyID NUMBER, CurrencyStartDate DATETIME, CurrentEndDate DATETIME) 

A continuación, puede excluir las monedas caducados de cualquier función de aplicaciones relacionadas con la actividad actual, y todavía mantiene la relación de los datos históricos.

Answer 8

Comercial DBMS (Informix, DB2, probablemente Oracle, ...) tienen capacidades de particionamiento o fragmentación tales que puede colocar datos diferentes en diferentes fragmentos, y el optimizador de consultas ignorará los fragmentos que sabe que no necesita. A veces puede usarlos para colocar los datos menos utilizados en áreas de almacenamiento que solo se usan para datos arcaicos. La ventaja de esto es que el sistema se ocupa de la ubicación (OK, el sistema más el DBA), y las aplicaciones son completamente ajenas a él.

Cualquier esquema que requiera cambios en las aplicaciones de informes está destinado a romper al menos algunas de esas aplicaciones.

Answer 9

Sugeriría separar el sistema operativo y el sistema de informes. Tenga una base de datos para el sistema operativo en línea y otra para los informes. (Podría ser un almacén de datos, o una simple otra base de datos) en función de cuán versátil sea el sistema de informes.

Mover periódicamente los datos del sistema operativo al sistema de informes. (la frecuencia depende de la naturaleza de su sistema). Todos los informes históricos se basarán en la base de datos de informes. La base de datos en línea también contendría informes, pero no (muy) históricos.

Y, sí. Debe mantener las fechas o los indicadores en las tablas para decidir si un elemento ha caducado .

Answer 10

Encontré una pregunta similar: What is the best way to implement soft deletion? que trata con la solución de indicador de actividad.

Y aquí hay otro en indicadores de actividad `active’ flag or not? para mysql y postgresql.

En base a estas dos preguntas, los indicadores de actividad y/o el particionamiento de la tabla son las soluciones más comunes al problema.

Answer 11

También puede actualizar los datos anteriores. Por ejemplo, puede convertir los montos de la lira italiana a importes en euros. Pero de hecho es una decisión caso por caso.Usted conoce su sistema y los requisitos mejor.