MS SQL - Migration MySQL dans une ancienne application Web

Question

Je souhaite migrer la base de données d'une application Web héritée de SQL Server vers MySQL. Quelles sont les limitations de MySQL que je dois surveiller? Et ce que tous les éléments feraient partie d'une liste de contrôle complète avant de se lancer dans la modification du code?

Answer 1

La première chose que je vérifierais, ce sont les types de données - la définition exacte des types de données varie d'une base de données à 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 vérifierais également les tables de données ou les colonnes qui ne sont pas utilisées maintenant. Aucun point en les migrant. Faites la même chose avec les fonctions, le travail, sps, etc. Il est maintenant temps de nettoyer les ordures.

Comment accédez-vous aux données via des requêtes dynamiques ou des requêtes dynamiques à partir de la base de données? Vérifiez chaque requête en lançant aganst une nouvelle base de données dev et assurez-vous qu'ils fonctionnent toujours. Encore une fois, il existe des différences entre les deux saveurs de SQl. Je n'ai pas utilisé mon sql donc je ne suis pas sûr de ce que certains des points d'échec communs sont. Pendant que vous y êtes, vous voudrez peut-être chronométrer de nouvelles requêtes et voir si elles peuvent être optimisées. L'optimisation varie également d'une base de données à l'autre et, pendant que vous y êtes, il y a probablement des requêtes peu performantes que vous pouvez corriger dans le cadre de la migration.

Les fonctions définies par l'utilisateur devront également être examinées. Ne les oubliez pas si vous faites cela. N'oubliez pas les travaux planifiés, ceux-ci devront également être vérifiés et recréés dans myslq.

Importez-vous des données régulièrement? Toutes les importations devront être réécrites.

La clé de tout est d'utiliser une base de données de test et de tester, tester, tester. Testez tout particulièrement les rapports trimestriels ou annuels ou les emplois 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 en production tant que vous n'avez pas exécuté tous les scripts dans l'ordre sur le dev sans échec.

Answer 2

Une chose que j'ai oubliée, assurez-vous que la base de données dev à partir de laquelle vous effectuez la migration (la base de données du serveur sql) est mise à jour à partir de la production immédiatement avant chaque test. Haine d'avoir quelque chose qui échoue sur prod parce que vous étiez en train de tester des enregistrements périmés.

Answer 3

Votre code client est presque certain d'être 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 quelque chose qui fonctionne de la même manière, même des choses auxquelles vous pourriez vous attendre.

Oui, les choses dans la base de données elle-même devront changer, mais le code client est où l'action principale est, il aura besoin de beaucoup de travail et de tests rigoureux. Oubliez la migration des données, c'est la dernière chose que vous devriez avoir en tête; 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 causer des problèmes, mais le code client est l'endroit où les problèmes seront les plus importants.

Presque chaque routine qui exécute une requête de base de données devra être changée, mais absolument tous devront être testés. Ce sera non trivial.

Je suis actuellement en train de migrer la base de données principale de notre application de MySQL 4.1 à 5, ce qui est beaucoup moins une différence, mais ce sera toujours une très, très grande tâche.