(Désolé de l'imprécision du titre, je ne peux pas penser comment dire vraiment ce que je cherche sans écrire un livre.)meilleure approche des vues sur les données d'archives avec les journaux de changement
Donc, dans notre application, nous permettons aux utilisateurs de modifier les éléments de données clés. Je garde des enregistrements de qui a changé quoi quand dans un schéma de notation, mais maintenant le problème se présente: comment est-ce que je représente au mieux ces données dans une vue pour signaler?
Un exemple permettra: les données d'un client (par exemple, l'adresse de facturation) ont changé le 04/04/09. Disons qu'aujourd'hui, 19/10/09, je veux voir tous leurs ordres de 2009, avant et après le changement. Je souhaite également que chaque commande affiche l'adresse de facturation en cours à la date de la commande.
J'ai donc 4 tables:
Les commandes (avec des données de commande) clients (avec des données clients actuelles) CustomerOrders (reliant les deux) CustomerChange (qui détient la date du changement, qui a fait le changement (id employé), ce que l'ancienne adresse de facturation était, et ce qu'ils changé à)
Comment puis-je la meilleure structure en vue d'être utilisé par des rapports afin que l'adresse correcte est retournée? Ou suis-je mieux servi en créant une base de données de rapports et en dénormalisant les données là-bas, ce que demande le groupe de rapports?
De bons points, mais j'ai trouvé un moyen de faire ce que je cherchais. En utilisant des CTE dans la vue et en filtrant par un MIN (DateDiff) qui est toujours> = 0, j'ai pu extraire les données appropriées des différentes tables. Les tests de performances indiquent qu'il s'agit en quelque sorte d'un lavage entre les données dénormalisées et la vue; Je ne m'attendais pas vraiment à ça! Depuis des rapports (et leur Mgmt, qui est le véritable ronce sous ma selle) veulent toujours des données dénormalisées, cependant, je pense que je vais séparer dehors dans une instance distincte pour minimiser l'impact d'avoir une table dénormalisé énorme sur une application db. – Valkyrie