Capacité dynamique de créer des transformations de données d'un ensemble de tables à un autre sur SQL Server

Question

J'ai un scénario dans lequel je reçois des fichiers d'une source et je vider aveuglément les données dans les fichiers dans une zone de transfert DB en nombre de tables . Maintenant, j'ai besoin de traduire les données dans les tables de données brutes dans un format que mon modèle de base de données primaire comprendrait et éventuellement faire un déplacement des tables traduites vers ma base primaire à partir de la zone de transit.

Par exemple, je peux avoir à joindre 3 tables dans les tables d'étape de données brutes et obtenir une liste finale de colonnes pour installer une table primaire finale qui est compatible avec mon DB principal. J'ai peut-être beaucoup de règles pour la traduction. Rejoindre est un.

Alors ma question est la suivante: Quelle est la meilleure façon de faire cela? Je prévois d'avoir une table de règles pouvant contenir la table Source, RuleSet, Table de destination et construire des requêtes dynamiquement dans une procédure stockée qui lirait les données de la table de règles, construirait des requêtes dynamiques telles que la requête créerait les tables primaires finales le format donné par la table.

Je suis à la recherche de meilleures idées ou de plus d'idées de conception sur cette idée de la part des experts pour la table de règles, afin de faire la traduction de façon transparente.

Édition: L'idée est que je vais réutiliser ce design DB pour plusieurs de nos instances. J'ai donc l'intention de remplir la table des règles et d'exécuter la procédure à la place en ayant un processus ETL pour chacune des instances.

Answer 1

Si vous avez une bonne compréhension de l'étendue des transformations possibles, vous pouvez probablement faire fonctionner ceci. Je suis un fan d'obtenir quelques exemples (peut-être plus difficiles) sous ma ceinture d'abord, avant d'essayer d'extraire un cadre, parce qu'un cadre sans bons cas d'utilisation peut 1) avoir des fonctionnalités inutilisées, 2) être difficile à configurer et être difficile à documenter, 3) échouer spectaculairement à répondre aux futurs cas d'utilisation

Cela ne veut pas dire qu'un framework ne peut pas être refactorisé, mais que refactoriser un framework dont vous savez déjà qu'il satisfait 80% de vos cas d'utilisation (parce que vous comprendre la portée) est beaucoup plus facile que de refactoriser celui qui ne répond que de 10% à un qui répond 20% à un qui répond à 30% etc.