2011-11-29 3 views
2

Nous concevons un processus d'archiver un ensemble d'enregistrements en fonction de différents critères comme la date, l'état, etc ...Concevoir un processus pour archiver les données (SQL Server 2005)

ensemble simplifiée de tableaux:Claim, ClaimDetails, StatusHistory (suit l'évolution de l'état de la revendication), Comments & Files

Environnement: SQL Server 2005, ASP.Net MVC (.NET Framework v3.5 SP1)

Claim est l'entité principale et comporte des lignes enfants dans les sous-tables mentionnées. Certains ont des détails et d'autres sont utilisés pour suivre les changements. Finalement, sur la base de certains critères, un Claim devient "prêt à archiver" comme expliqué ci-dessus. En mots simples archivés Claims seront identifiés à partir de la base de données et traités différemment dans l'application web.

Voici une version la plus simple: (vue de dessus)

  • Créer un script qui marque un Claim "archivé" dans db.
  • La ligne archivée et ses lignes enfants peuvent être conservées dans la même table (définir un drapeau) ou déplacées vers une autre table qui sera une réplique de celle d'origine.
  • Dans l'application Web, nous laisserons l'utilisateur filtrer Claims en fonction de l'état de l'archive.
  • Il se peut qu'il soit nécessaire de "désarchiver" un Claim dans le futur.

Ce que j'ai besoin de savoir?

  1. Nous devons garder cela aussi simple et facile que possible et aussi flexible pour adapter les changements futurs - pls proposer une approche. Un script SQL planifié opportun est-il la meilleure option pour ce scénario?

  2. Dois-je envisager d'utiliser des tables séparées ou simplement ajouter un drapeau «Archivé» à chaque table?

  3. Pour la considération de la performance de l'approche choisie - quelle différence cela ferait-il si nous prévoyons d'avoir environ 10 000 Claims et si son 1 million. En bref SVP mentionner une légère approche & de charge lourde.

  4. Nous stockons les fichiers chargés physiquement sur notre serveur - je crois que cela peut rester tel quel.

Note: Une demande peut avoir un nombre quelconque d'enregistrement enfant (s) dans toute la table mentionné il obtient n fois.

Existe-t-il un cadre ou un modèle standard que je devrais consulter pour en savoir plus sur le processus d'archivage. N'importe quel article ou outil de référence pourrait m'aider à en savoir plus.

Répondre

2

Vous pouvez trouver une bonne discussion sur ce sujet here et this en est une autre.Le fait d'avoir des données archivées dans un tableau séparé offre plus de flexibilité, par exemple si vous souhaitez suivre l'utilisateur ayant marqué une revendication comme archivée ou la date d'archivage d'une revendication ou pour voir toutes les modifications apportées à une revendication après sa création.

+0

Merci, mais cela ressemble plus à la maintenance du journal DB à chaque modification. J'ai besoin de quelque chose qui maintient le "Archive" une fois l'enregistrement archivé, il devient en lecture seule, il n'est donc pas nécessaire de maintenir plusieurs versions. En outre, nous parlons de quelques millions de dossiers sur une période de 2-3 ans. –

+1

Avoir un indicateur Archivé sur chaque table est la solution la plus simple, mais ce n'est pas une approche très flexible pour les changements futurs que vous pourriez avoir. Vous devez également prendre en compte la fréquence d'utilisation des données archivées dans vos applications. Si les revendications actives sont plus souvent consultées que celles archivées, la création d'une table distincte pour les revendications archivées améliore les performances, car vous interrogerez un petit ensemble de données. – kishore