Quelle est la meilleure stratégie pour conserver de grands ensembles de données ?

Question

Je dirige un projet dans lequel nous enregistrerons des données métriques.J'aimerais conserver les données pendant des années.Cependant, j'aimerais également éviter que le tableau principal ne soit saturé de données qui, bien que nécessaires pour les tendances à long terme, ne sont pas nécessaires pour les rapports à court terme.

Quelle est la meilleure stratégie pour gérer cette situation ?Archiver simplement les anciennes données dans une autre table ?Ou « regrouper » via une consolidation des données elles-mêmes (puis les stocker dans une autre table) ?Ou tout autre chose ?

Information additionnelle:nous utilisons SQL Server 2005.

Answer 1

Nous utilisons les deux méthodes dans mon travail, mais légèrement différentes, nous conservons toutes les données de ventes dans le tableau principal pendant 30 jours, puis la nuit (une partie des tâches nocturnes), les ventes du jour sont regroupées dans des résumés (n quantité de x produit vendu aujourd'hui ect) dans un tableau séparé pour des raisons de reporting, et les ventes de plus de 30 jours sont archivées dans une base de données différente, puis une fois par an (nous passons par années fiscales), une nouvelle base de données d'archives est démarrée.pas vraiment parfait mais..

De cette façon, nous obtenons rapidement les données récapitulatives, gardons toutes les données de ventes actuelles à portée de main et disposons d'un espace illimité pour les données d'archives détaillées.nous avons essayé de tout conserver dans une seule base de données (dans différentes tables), mais la taille du fichier de la base de données (interbase) deviendrait si grande qu'elle entraînerait le système vers le bas.

le seul vrai problème que nous avons est d'accéder à des données détaillées qui s'étendent sur plusieurs bases de données, car la connexion et la déconnexion sont lentes et l'analyse doit être effectuée en code plutôt qu'en SQL.

Answer 2

Si vous utilisez SQL Server 2005, cela peut être un bon candidat pour utiliser tables partitionnées.

Answer 3

En fonction des contraintes telles que le budget, etc., cela semble être un candidat parfait pour une application d'entrepôt de données.Cela introduirait généralement un nouveau serveur à utiliser comme entrepôt de données.SQL Server 2005 prend en charge une grande partie de cette activité dès le départ. En outre, vous pourrez peut-être utiliser des services SQL Server supplémentaires (par ex.Analysis Services, Reporting Services) pour apporter une valeur supplémentaire à vos utilisateurs.(voir http://www.microsoft.com/technet/prodtechnol/sql/2005/dwsqlsy.mspx)

Answer 4

@Jason - Je ne vois pas comment conserver les données dans d'anciens fichiers texte vous permettra d'effectuer facilement une analyse des tendances à long terme sur les données.

@Jason - Je suppose que mon point est que si une sorte d'analyse ad hoc (c'est-à-diretendances) doit être effectué sur les données par des professionnels, le regroupement ou l'archivage des données dans des fichiers texte ne résout vraiment aucun problème.Bien sûr, écrire du code pour utiliser un fichier texte est facile dans de nombreuses langues, mais ce problème a été résolu.De plus, je dirais que les SGBDR actuels sont tous extrêmement durables lorsqu'ils sont configurés et entretenus correctement.Si ce n'était pas le cas, pourquoi dirigeriez-vous une entreprise par-dessus une autre (et encore moins y archiver des données) ?Je ne vois tout simplement pas l'intérêt d'archiver dans un fichier texte brut en raison de l'affirmation selon laquelle la durabilité des fichiers texte est supérieure à celle des bases de données.

Answer 5

Chacune de ces options est excellente, mais cela dépend vraiment du domaine du problème.Pour des choses comme les soldes de trésorerie ou les données statistiques, je pense que regrouper les enregistrements et les consolider est le meilleur moyen. Vous pouvez ensuite déplacer les enregistrements cumulés dans une table d'archives parallèle, en les saisissant de manière à pouvoir les "dérouler" si nécessaire.Cela permet de conserver votre table de données principale propre et rapide, mais vous permet de conserver les données supplémentaires à des fins d'audit ou autre.La question clé est de savoir comment mettre en œuvre le processus de « cumul ».Soit automatiquement, via un déclencheur ou un processus côté serveur, soit par intervention de l'utilisateur au niveau de l'application ?