¿Cuál es la mejor estrategia para retener grandes conjuntos de datos?

Question

Estoy liderando un proyecto en el que vamos a registrar datos de métricas. Me gustaría conservar los datos durante años. Sin embargo, también me gustaría evitar que la tabla principal se hinche con datos que, aunque son necesarios para las tendencias a largo plazo, no son necesarios para los informes a corto plazo.

¿Cuál es la mejor estrategia para manejar esta situación? Simplemente archivar los datos antiguos en otra tabla? ¿O "enrollarlo" mediante una consolidación de los datos en sí (y luego almacenarlo en una tabla diferente)? ¿O algo completamente diferente?

Otros detalles: estamos utilizando SQL Server 2005.

Answer 1

Utilizamos ambos métodos en mi trabajo, pero ligeramente diferente, mantenemos todos los datos de ventas en la tabla principal durante 30 días, luego en la noche (parte de los trabajos nocturnos) los días las ventas se acumulan en resúmenes (n cantidad de X producto vendido hoy ect) en una tabla separada por razones de informes, y las ventas de más de 30 días se archivan en una base de datos diferente, luego una vez al año (estamos en años fiscales) se inicia una nueva base de datos de archivo. no exactamente perfecto, pero ...

de esta manera obtenemos los datos de los resúmenes rápidamente, tenemos todos los datos de ventas actuales y tenemos un espacio ilimitado para los datos de archivo detallados. intentamos mantenerlo todo en una base de datos (en diferentes tablas) pero el tamaño del archivo de la base de datos (interbase) crecería tanto que arrastraría al sistema hacia abajo.

el único problema real que tenemos está accediendo a datos detallados que se extiende por varias bases de datos, como la conexión y desconexión es lento, y el análisis se tiene que hacer en el código en lugar de SQL

Answer 2

Cualquiera de esas opciones son excelentes, pero realmente depende del dominio del problema. Para cosas como saldos de caja o datos estadísticos, creo que enrollar los registros y consolidarlos es la mejor manera, luego puede mover los registros acumulados a una tabla de archivo paralela, insertándolos de tal forma que pueda "desenrollar" si necesario. Esto mantiene su tabla de datos primaria limpia y rápida, pero le permite retener los datos adicionales para la auditoría o lo que sea. La pregunta clave es, ¿cómo se implementa el proceso de "roll-up"? ¿Automáticamente, a través de un proceso desencadenante o del lado del servidor, o mediante la intervención del usuario en el nivel de la aplicación?

Answer 3

Si está utilizando SQL Server 2005, esta puede ser un buen candidato para usar partitioned tables.

Answer 4

@Jason - No veo cómo el mantenimiento de los datos en archivos de texto antiguos le permitirá hacer análisis de tendencias a largo plazo fácilmente en los datos.

@Jason - Supongo que mi punto es que si los empresarios deben realizar algún tipo de análisis ad-hoc (es decir, tendencias) sobre los datos, enrollar o archivar los datos en archivos de texto realmente no resuelve cualquier problema Por supuesto, escribir código para consumir un archivo de texto es fácil en muchos idiomas, pero ese problema se ha resuelto. Además, yo diría que los RDBMS actuales son extremadamente duraderos cuando se configuran y se mantienen de forma adecuada. Si no lo fueran, ¿por qué llevarías un negocio encima de uno (y mucho menos archivar datos)? Simplemente no veo el objetivo de archivar en un archivo de texto sin formato debido a la afirmación de que la durabilidad de los archivos de texto es superior a la de las bases de datos.

Answer 5

Dependiendo de las limitaciones como presupuesto, etc., esto suena como un candidato perfecto para una aplicación de depósito de datos. Esto normalmente presentaría un nuevo servidor para usar como almacén de datos. SQL Server 2005 es compatible con gran parte de esta actividad, además, es posible que pueda utilizar servicios adicionales de SQL Server (por ejemplo, Analysis Services, Reporting Services) para proporcionar un valor adicional a sus usuarios. (Consulte http://www.microsoft.com/technet/prodtechnol/sql/2005/dwsqlsy.mspx)