Transfert de données de production db vers datawarehouse (SQL Server)

Question

Nous développons un module de reporting pour notre logiciel, et pour cette raison, nous devons déplacer certaines données de la production db du système dans un datawarehouse db qui sera utilisé comme source de données pour les rapports (rapports SQL Server). Le schéma dans la base de données de production est assez ancien, donc une fois que nous avons des données dans la base de données DW, nous aurons besoin de champs supplémentaires (par exemple, calcul d'une colonne datetime correcte de la date et de l'heure). 'colonnes entières. (Ne pas demander, c'est vieux.)

Nous discutons en interne de la façon efficace de le faire.Pour l'instant, il est implémenté dans un travail SSIS fugly qui décompose fondamentalement toute la DB DW toutes les nuits et le reconstruit à partir de la base de données, en faisant des transformations de données au fur et à mesure ..

Je cherchais à utiliser des technologies «plus récentes», comme la réplication de SQL Server par exemple déplacer des données i n une mode plus granulaire. Mes questions à ce sujet sont les suivantes: -Avec la réplication, la partie "déplacer des données" est évidemment résolue, mais pas la partie de transformation de données. Je sais que je peux créer des déclencheurs de mise à jour sur la base de données DW, mais tous les déclencheurs liés aux tables semblent être effacés chaque fois que je réinitialise l'abonnement, ce qui le rend difficile à configurer.

Je ne cherche pas une réponse exacte ici, plus un indice sur la direction à prendre. Désolé si la question est un peu floue.

mise à jour: merci pour les bons points ci-dessous. C'est un logiciel que nous vendons aux clients, donc je suis un grand fan d'avoir le moins possible d'éléments de configuration pour le client à installer et à maintenir. Le paquet SSIS tel qu'il est aujourd'hui est un autre "élément" pour le client de garder un œil sur, ainsi que ses horaires. La réplication m'a intrigué parce qu'elle absitue complètement le "dilemme" CRUD entier lors du déplacement des données, mais vous avez peut-être raison - SSIS serait encore mieux, tant que la logique SSIS est créée un peu plus intelligemment qu'aujourd'hui.

Les données peuvent être assez volumineuses, alors effacer et réimporter tout ce que nous faisons aujourd'hui est définitivement un problème qui doit être adressé .

Answer 1

Je ne pense pas que la réplication soit une bonne idée. Ce serait si les schémas de source et de destination étaient exactement les mêmes, mais comme vous l'avez souligné, ils ne le sont pas. Et aussi, tous les calculs que vous mentionnez le SSIS font, vous devriez toujours le faire parce que la réplication ne le ferait pas.

Je pense que SSIS est la voie à suivre, je veux dire, c'est exactement pourquoi il existe. Comme vous recréer la base de données sur chaque chargement et si la quantité de calculs et de modifications n'est pas importante et que vous n'avez pas besoin de rechercher des clés de substitution à partir de clés naturelles, vous pouvez créer des vues sur votre base de données principale. pour essayer d'imiter la structure de la base de données de destination afin que vous puissiez faire des insertions directes (à peu près un composant source mappé à un composant de déstibution)

peut-être si vous spécifiez quel est le vrai problème avec SSIS que vous voulez résoudre, il serait plus facile d'aider.

Answer 2

Juste une mise à jour rapide sur ceci: La fonctionnalité CDC de SQL Server semble être ce que nous devons examiner, cette fonctionnalité s'intègre bien avec SSIS. Merci pour l'indice sur lentement changer les dimensions, et SSIS!