Conception d'instantanés dans une base de données transactionnelle avec gestion des versions des données de référence

Question

Clause de non-responsabilité: j'ai lu tout ce que je peux lire sur le thème des instantanés et du contrôle de version sur le débordement de pile et sur Internet. Mon exigence n'est pas le suivi de version pour la piste d'audit ou les instantanés au niveau de la base de données. J'ai passé plus d'une semaine à faire des recherches par moi-même et à réfléchir aux options possibles. Désolé, j'aurais pu manquer certains liens - si la solution à mon problème est déjà discutée dans un autre fil, veuillez m'indiquer là.

C'est un peu long; Veuillez patienter avec moi.

Voici la situation: nous essayons de créer une conception générique pour stocker des instantanés des données transactionnelles dans notre base de données transactionnelle et aussi pour conserver un historique des révisions des données de référence.

Dans le cadre du processus métier, un utilisateur peut appuyer sur un bouton pour publier certains objets. À des fins d'illustration, disons que l'utilisateur peut publier une proposition du fournisseur avant le début de la négociation. Ensuite, à différents moments du processus de négociation, l'utilisateur peut publier les données de la proposition. La proposition contient un budget, des objectifs de vente et de nombreux autres éléments. Lorsqu'une proposition est instantanée, toutes les entités liées doivent être instantanées. Enfin, après la négociation, un contrat est signé. À ce stade, un instantané complet du contrat doit être créé. Toutes les entités du contrat ne sont pas présentes dans la proposition - il y a beaucoup d'entités qui se chevauchent, mais il y a des entités uniques attachées à la proposition et au contrat.

Nous devons conserver à la fois ces versions publiées et les dernières versions actives disponibles. Les versions publiées sont mises à disposition sur un site Web pour être référencées par les deux fournisseurs ainsi que par l'équipe de direction. Toutes les versions publiées ne sont pas disponibles sur le site Web, mais la dernière proposition publiée et le dernier contrat publié sont toujours disponibles sur le site Web. Ce site Web doit également être alimenté à partir de la même base de données.

En outre, un utilisateur financier peut décider de prendre un instantané uniquement du budget et un directeur des ventes peut instantané des objectifs de vente. Ainsi, les instantanés sont disponibles avec plusieurs granularités.

Nous avons également l'obligation de suivre les versions des données de base. Il est impératif de suivre toutes les modifications apportées aux colonnes de données de base clés au fil du temps. Par exemple, nous avons des informations régionales associées aux objectifs de vente. Le nom de la région peut changer et nous voulons suivre ces changements. Supposons qu'au moment de la proposition, le nom de la région soit R1 et qu'un instantané soit créé. Ensuite, le nom de la région devient R2 et 2 autres instantanés sont créés. Nous voulons pouvoir lier les objectifs de vente au nom de région correct à ces moments, pas nécessairement au dernier nom de région.

Nous avons une certaine flexibilité dans la modélisation car nous avons à la fois une base de données de transaction et une base de données d'entrepôt de données et nous pouvons décider de stocker certaines de ces informations soit dans la base de données de transaction, soit dans la base de données de l'entrepôt de données.

Voici notre conception. Nous avons un tableau de publication qui capture des informations de base sur les données publiées - qui a publié et la date, la raison et le type d'objet publié (proposition ou budget ou objectifs de vente).

Nous stockons les instantanés dans la même table que les données d'origine. Ainsi, les instantanés de proposition seraient stockés avec les propositions en direct dans le tableau des propositions. Nous avons une colonne appelée ID de publication dans chaque table qui doit être publiée. Cette colonne est un FK de la table Publication. Si l'ID de publication est nul, cet enregistrement est la version active.

J'ai réalisé que le message était très long. Par conséquent, plutôt que d'énumérer les détails du scénario, j'ai pensé à résumer rapidement les considérations de conception dans une carte mentale.

Maintenant, il y a 2 solutions vers lesquelles nous nous tournons - les deux stockeraient un instantané de toutes les données, qu'elles aient changé ou n

ot. Conserver uniquement le delta tout en conservant les structures de table intactes nécessiterait une procédure stockée très complexe qui doit s'exécuter à chaque insertion / mise à jour de l'un des objets instantanés. Je ne veux pas emprunter cette voie car cela prendrait plus de temps et les volumes ne sont pas si énormes de toute façon.

Solution 1: Chaque fois qu'un objet est publié (comme une proposition ou un budget), nous remplissons une arborescence XML et la persiste dans la base de données. Seule la dernière version doit être disponible sur le site Web et les anciennes versions sont rarement nécessaires. Compte tenu de cela, est-ce que je rencontrerais un gros problème de performances en raison de l'utilisation de XML? Nous utilisons SQL Server. Les volumes de données ne sont pas énormes.

Solution 2: Toutes les tables de transaction auraient un ID de publication et les données de référence auraient des dates de début et de fin. Chaque fois qu'un objet est publié, nous ferions une copie de tous les enregistrements de transaction et y mettions l'ID de publication et nous copions tous les enregistrements de données de référence et mettions une date d'instantané comme date de fin. Cela nous permettrait d'avoir une gestion des versions normale pour les données de référence en dehors du processus de publication.

J'aurais besoin des opinions d'esprits expérimentés ici quant aux inconvénients de ces 2 approches et s'il existe un autre meilleur scénario.

Answer 1

Mon approche serait d'opter pour la solution 2. En prenant vos considérations de conception dans l'ordre:

1. Je conserverais une copie de tout ce qui se trouve dans l'instantané. Si vous stockez uniquement la modification, vous vous posez le problème de la capture instantanée des détails du processus pour obtenir l'instantané souhaité à partir des modifications. Au départ, ce n'est pas un problème, mais à mesure que les schémas, les programmes et les processus changent, vous devrez conserver les détails sur la façon de récupérer l'instantané souhaité à partir d'un processus qui a lui-même changé. Faisable, mais potentiellement fragile.

2. J'opterais pour une option non mentionnée dans votre diagramme, bien qu'esquissée dans votre description de la solution 2. Cela utilise un schéma très similaire à celui de la transaction DB, mais étendu pour inclure les informations spécifiques à les instantanés. Vous mentionnez l'ID de publication comme clé étrangère et les dates des données de référence. Vous pourriez avoir besoin d'informations supplémentaires telles que les dates, liées aux données de transaction.

3. Le même schéma ne fonctionnera pas - vous avez souligné (ID de publication) que le même schéma n'est pas adéquat. Rien dans ce que vous publiez ne suggère que vous devez adopter un schéma différent optimisé pour la lecture. Même si cela s'avère nécessaire, c'est quelque chose qui peut être incorporé à un stade ultérieur, avec le schéma étendu actuel comme point de départ. Je n'ai pas beaucoup d'expérience avec les arbres XML, mais je demanderais "pourquoi introduire une autre technologie alors que vous avez des alternatives qui peuvent utiliser votre infrastructure existante?" Tout avantage que vous percevez de cette approche devrait être très important pour éviter de perdre l'avantage de l'effet de levier de votre architecture existante. Des considérations similaires s'appliquent à une base de données dénormalisée. Pourquoi y aller jusqu'à ce qu'il y ait un besoin démontré de le faire?

4. Encore une fois, j'adopterais l'approche du suivi des versions et des instantanés. Vous donnez un avantage principal de cette approche dans votre solution 2. J'ajouterais la capture instantanée des données de référence dans le cadre du processus de capture instantanée, plutôt que le processus de gestion des versions. (Par exemple, lorsqu'un instantané est pris, assurez-vous que les tables de référence appropriées font partie de l'instantané). Il semble d'après votre description que vous avez deux exigences différentes qui utilisent les mêmes données: la capture instantanée et le contrôle de version. Il semble y avoir peu de dépendance entre eux, et vous devriez donc les garder aussi indépendants que possible - manque de couplage.

5. Vous mentionnez l'utilisation potentielle de l'entrepôt de données comme stockage, bien que cela ne soit pas spécifiquement mentionné dans vos solutions. Si vos volumes sont, comme vous le suggérez, faibles, alors j'aurais pensé qu'une base de données distincte était adéquate. Vous donnez l'impression que les volumes de données et d'utilisateurs pour les instantanés sont faibles, il ne semble donc pas y avoir de justification prima facie pour l'utilisation de l'entrepôt de données. En même temps, l'entrepôt dispose de certains mécanismes pour stocker exactement ce type de données historiques, à utiliser pour la lecture et l'analyse.

Je suis désolé de ne pas avoir répondu directement à vos questions ici - mais j'espère que cela vous donnera quelques indications et un autre point de vue sur votre situation déclarée.