MS SQL - Migration MySQL dans une application Web existante

Question

Je souhaite migrer la base de données d'une application Web héritée de SQL Server vers MySQL. Quelles sont les limites de MySQL que je dois rechercher? Et quels éléments feraient tous partie d’une liste de contrôle exhaustive avant de modifier réellement le code?

Answer 1

La première chose que je voudrais vérifier concerne les types de données: la définition exacte des types de données varie d’une base à l’autre. Je voudrais créer une liste de mappage qui indique à quoi mapper chacun des types de données. Cela aidera à construire les nouvelles tables. Je voudrais également vérifier les tables de données ou les colonnes qui ne sont pas utilisées maintenant. Inutile de les migrer. Faites la même chose avec les fonctions, le travail, les sps, etc. Le moment est venu de nettoyer les fichiers indésirables.

Comment accédez-vous aux données via sps ou des requêtes dynamiques à partir de la base de données? Vérifiez chaque requête en l'exécutant contre une nouvelle base de données dev et assurez-vous qu'elles fonctionnent toujours. Là encore, il existe des différences entre le fonctionnement des deux types de SQL. Je n'ai pas utilisé mon SQL donc je ne suis pas sûr de ce que certains des points de défaillance courants sont. Pendant que vous y êtes, vous voudrez peut-être chronométrer les nouvelles requêtes et voir si elles peuvent être optimisées. L’optimisation varie également d’une base de données à l’autre et, tant que vous y êtes, il existe probablement actuellement des requêtes peu performantes que vous pouvez résoudre dans le cadre de la migration.

Les fonctions définies par l'utilisateur devront également être examinées. Ne les oubliez pas si vous le faites.

N'oubliez pas les travaux planifiés, ils devront également être vérifiés et recréés dans myslq.

Importez-vous des données selon un calendrier régulier? Toutes les importations devront être réécrites.

La clé de tout consiste à utiliser une base de données de test et à tester, tester, tester. Testez tout, en particulier les rapports trimestriels ou annuels ou les travaux que vous pourriez oublier.

Une autre chose que vous voulez faire est de tout faire à travers des scripts contrôlés par la version. Ne passez pas à la production avant d'avoir pu exécuter tous les scripts dans l'ordre sur dev sans échec.

Answer 2

Une chose que j'ai oubliée est de vous assurer que la base de données dev à partir de laquelle vous exécutez la migration (la base de données du serveur SQL) est mise à jour dès la production immédiatement avant chaque test. Déteste que quelque chose échoue sur prod parce que vous testiez des enregistrements obsolètes.

Answer 3

Votre code client est presque certainement la partie la plus complexe à modifier. À moins que votre application ne dispose d'une suite de tests de très haute qualité, vous devrez faire beaucoup de tests. Vous ne pouvez pas compter sur quoi que ce soit qui fonctionne de la même manière, même les choses auxquelles vous pouvez vous attendre.

Oui, les éléments de la base de données eux-mêmes devront changer, mais le code client est l’action principale; il faudra donc des tonnes de travail et des tests rigoureux.

Oubliez la migration des données, c’est la dernière chose qui devrait vous préoccuper; le schéma de base de données peut probablement être converti sans trop de difficulté; D'autres objets de base de données (SP, vues, etc.) peuvent être à l'origine de problèmes, mais le code client est le centre des problèmes.

Presque toutes les routines exécutant une requête de base de données devront être modifiées, mais absolument toutes devront être testées. Ce ne sera pas trivial.

J'envisage actuellement de migrer la base de données principale de notre application de MySQL 4.1 à 5, ce qui est bien moins différent, mais ce sera quand même une très grosse tâche.