Méthode recommandée pour interroger plusieurs tables versionnées

Question

Avoir une boîte Win 2003 avec MSSQL 2005 en cours d'exécution. Il y a une base de données qui est remplie chaque matin avec SalesOrder nouveau/modifié fait le jour précédent. La base de données comporte plusieurs tables: SalesOrder, SalesOrderItem, SalesOrderItemBom. Chacun avec une table Version correspondante (c'est-à-dire SalesOrderVersion, SalesOrderItemVersion, SalesOrderItemBomVersion) qui a exactement les mêmes champs mais avec 2 colonnes d'addition VersionStartDate, VersionEndDate. Les tables non-versionnées ont les dernières données.

De même, VersionStartDate fait partie du PK pour les tables de versions, par exemple: - SalesOrder a OrderID comme PK et SalesOrderItem a VersionStartDate, OrderID comme PK.

Un exemple simplifié de la façon dont la table version fonctionne:

SalesOrder

OrderID, Montant 1, 100 2, 200

SalesOrderVersion

VersionStartDate, OrderID , VersionEndDate, Montant 20090101 13 : 00: 00, 1, 20090103 08:00:00, 50 20090103 08:00:00, 1, 99991231 00:00:00, 100 20090101 09:00:00, 2, 20090105 15:00:00, 300 20090105 15:00:00, 2, 99991231 00:00:00, 200

chaque fois que l'une ligne dans SalesOrder est modifiée, la ligne courante VersionEndDate dans SalesOrderVersion est mis à jour et une nouvelle ligne est insérée dans SalesOrderVerion avec VersionEndDate 99991231

notes: Si un enregistrement dans SalesOrderItem a été changé, il ne résulte pas nécessairement un changement dans le dossier « parent » dans SalesOrder

ont été invités à faire un rapport montrant la tendance et par jour les augmentations des ventes. Au sommet de ma tête, je pensais à créer 3 tableaux instantanés pour SalesOrder, SalesOrderItem, SalesOrderItemBom, qui capturent les "dernières données" de la journée et construisent ainsi des snapshots incrémentaux pour montrer les tendances. En plus d'exiger plus d'espace disque, y at-il un inconvénient à cette méthode par rapport à l'exécution d'une procédure stockée qui rejoint les tables Version, car cela semble être une requête longue et coûteuse.

Des idées ou des recommandations?

Answer 1

Il y a beaucoup de "ça dépend" ici. Voici quelques idées de discussion.

Les données sont-elles chargées uniquement le matin? Cela signifie que les données ne changent pas au cours de la journée, de sorte que des requêtes longues et coûteuses ne provoqueraient pas de problèmes de verrouillage ou de blocage. Cette base de données est-elle utilisée uniquement pour les rapports? Si ce n'est pas le cas - si les données sont mises à jour tout au long de la journée, des copies redondantes supplémentaires des données peuvent être nécessaires pour répondre à vos besoins.

À quelle fréquence les nouveaux rapports seront-ils exécutés? Seront-ils courus plusieurs, plusieurs fois pour un jour donné, ou seulement une ou deux fois? Si les données "agrégées dans le temps" vont être accessibles encore et encore, faire une copie redondante (l'instantané) peut être utile, mais si les rapports vont être exécutés une ou deux fois et ensuite jeté, je ne sais pas que je dérange.

Quelle est l'importance des performances? Les rapports doivent-ils être générés et terminés dans les deux à trois secondes qui suivent la frappe d'un bouton sur un bouton?(pause) Non, vraiment, surtout quand vous leur expliquez le coût en dollars (espace disque supplémentaire, espace de sauvegarde supplémentaire, temps supplémentaire pour préparer et sauvegarder et restaurer, quels que soient les autres coûts de furtivité). S'ils peuvent attendre quelques minutes pour obtenir des rapports une fois par jour, alors faites-le moins cher. (Vous avez encore le coût initial de l'écriture de code plus complexe, mais une fois qu'il est fait, il est fait.)

D'un autre côté, l'ajout d'une routine pour générer après chargement de données du jour le rapport du jour, et ne garder qu'un seul ensemble de données (ou peut-être un ensemble de données pour la semaine dernière, quatre semaines, peu importe) a un fort attrait. Si vous savez qu'ils vont exécuter ce rapport de 5 minutes, lancez-le dans l'AM afin qu'il soit prêt quand ils entrent.

Tout cela est basé sur des conjectures à vos besoins opérationnels. Comme je l'ai dit, tout dépend de ce que vous avez et de ce dont vous avez besoin.