Transfert de données MySQL vers SQL Server

Question

J'ai besoin de convertir des données qui existent déjà dans une base de données MySQL vers une base de données SQL Server. L'inconvénient ici est que l'ancienne base de données a été mal conçue, mais la nouvelle est sous une forme 3N appropriée. Est-ce que quelqu'un a des conseils sur la façon de s'y prendre? J'ai SSMS 2005.

1. Puis-je l'utiliser pour me connecter à la base de données MySQL et créer un DTS? Ou dois-je utiliser SSIS?
2. Ai-je besoin d'écrire un script sur la base de données MySQL et de modifier chaque instruction pour "insérer" dans la base de données SQL Server?

Quelqu'un at-il déjà vécu cela? S'il vous plaît HELP !!!

Answer 1

Voir this link. L'idée est d'ajouter votre base de données MySQL en tant que serveur lié dans SQL Server via le pilote MySQL ODBC. Ensuite, vous pouvez effectuer toutes les opérations que vous voulez sur la base de données MySQL via SSMS, y compris la copie de données dans SQL Server.

Félicitations pour votre progression dans le monde des SGBDR!

Answer 2

Vous avez besoin d'un outil ETL (extraire, transformer, charger).

http://en.wikipedia.org/wiki/Extract,_transform,_load#Tools

Answer 3

Je ne sais pas vraiment à quel point un outil « ETL » vous obtiendrez en fonction des modèles de bases de données originales et nouvelles. Dans ma carrière j'ai dû faire plus que quelques migrations de données et nous devions toujours concevoir un utilitaire spécial qui mettrait à jour une nouvelle base de données avec les enregistrements de l'ancienne base de données, et oui nous l'avons codé avec toutes les mises à jour/insertions déclarations qui transformeraient les données.

Je ne sais pas combien de tables votre base de données a, mais si elles ne sont pas trop nombreuses alors vous pourriez envisager d'aller à la racine. C'est une technique qui fonctionne après tout.

Answer 4

Je l'ai fait aller dans l'autre direction et SSIS fonctionne bien, même si j'ai peut-être besoin d'utiliser une tâche de script pour faire face à une légère bizarrerie de type de données. SSIS does ETL.

Answer 5

Si vous allez dans votre base de données dans SSMS et cliquez avec le bouton droit de la souris, sous les tâches devrait être une option pour "Importer des données". Vous pouvez essayer d'utiliser cela. Il s'agit simplement d'un assistant qui crée un package SSIS pour vous, qu'il peut ensuite exécuter automatiquement pour vous ou que vous pouvez enregistrer puis modifier au besoin.

Le gros problème est de savoir comment vous devez transformer les données. Cela va dans beaucoup de détails que vous n'incluez pas (et qui sont probablement trop nombreux pour que vous incluiez ici de toute façon).

Je suis certain que SSIS peut gérer toutes les transformations que vous devez faire pour le passer de l'ancien format au nouveau. Une alternative serait de simplement importer les tables dans MS SQL tel quel dans les tables de transfert, puis d'utiliser du code SQL pour transformer les données dans les tables 3NF. Tout dépend de ce qui vous convient le mieux. Si vous allez sur la deuxième route, le processus d'importation que j'ai mentionné ci-dessus dans SSMS pourrait être utilisé. Il va même créer les tables de destination pour vous. Assurez-vous simplement de leur donner des noms uniques, en les préfixant peut-être avec "STG_" ou quelque chose comme ça.

Davud a mentionné les serveurs liés. C'est certainement une autre façon que vous pouvez aller (et obtenu mon upvote). Personnellement, je préfère d'abord copier les tableaux dans MS SQL, car les serveurs liés peuvent parfois être bizarres, en particulier quand il s'agit de types de données qui ne sont pas mappés entre différents fournisseurs.Avoir les tables toutes en MS SQL sera également probablement un peu plus rapide et gagner du temps si vous devez relancer ou corriger des parties des données. Comme je l'ai dit cependant, la méthode du serveur lié serait probablement bien aussi. SSIS est conçu pour faire ce genre de choses.

Answer 6

La première étape consiste à cartographier manuellement où chaque élément de données ira dans la nouvelle structure. Donc, votre ancienne table avait quatre champs, dans votre nouvelle structure fileds1 et 2 vont à la table a et les champs trois et quatre vont à la table b, mais vous devez également avoir l'identifiant autogénéré de la table a. Prenez des notes sur l'endroit où les types de données ont changé et vous devrez peut-être faire des ajustements ou lorsque vous avez besoin de fichiers où les données n'étaient pas nécessaires auparavant.

Ce que je fais habituellement est de créer des tables de transfert. Placez les données dans le formulaire dénormalisé dans une table de transfert, puis déplacez-vous vers des tables de transfert normalisées et effectuez le nettoyage et ajoutez les nouveaux identifiants dès que vous les avez dans les tables de transfert. Une chose que vous devrez faire si vous passez d'une base de données dénormalisée à une base normalisée est que vous devrez éliminer les doublons des tables parent avant de les insérer dans les tables de production réelles. Vous pouvez également avoir besoin de faire des opérations de données dans la nouvelle structure qui ne sont pas nécessaires dans les anciens problèmes de conversions de données, par exemple si vous avez stocké des dates dans l'ancienne base de données dans les champs varchar mais déplacer correctement datetime dans le nouveau db, vous pouvez avoir des dossiers qui ne sont pas des dates valides.

Une autre question que vous devez penser à comment vous allez convertir les anciens ids record aux nouveaux.

Ce n'est pas une tâche facile, mais il est faisable si vous prenez votre temps et travaillez méthodiquement.Il n'est pas temps d'essayer des raccourcis