Je me présente, je m'appelle Alfredo Riveros et j'apprends la programmation depuis quelques années, j'étudie actuellement Technicien Supérieur en Développement Logiciel à l'École Supérieure de Commerce - Río Tercero, et ci-dessous je décrirai un défi que je rencontré.

Comme le titre l'indique, mon objectif était de migrer une base de données SQLite vers MySQL, ce qui découle d'une mission dans le domaine de la base de données que je suis.

La base de données que j'ai sélectionnée appartient au jeu SQL Murder Mystery. Ce jeu, créé pour enseigner les compétences SQL de manière ludique, est disponible sur ce lien, où vous pouvez télécharger la base de données fournie par ses développeurs.

J'ai choisi cette base de données pour son orientation pédagogique, étant donné que bien qu'elle soit un jeu en soi, elle constitue une ressource précieuse tant pour l'enseignement que pour l'apprentissage des concepts liés aux bases de données.

Ma première étape dans ce défi a été de déterminer si je pouvais utiliser DB Browser for SQLite pour exporter la base de données dans un format compatible avec MySQL Workbench. Bien que j'aie réussi à générer un script SQL à partir de DB Browser, son importation dans Workbench présentait de nombreux problèmes, notamment de syntaxe et d'intégrité des données, en plus de la complexité de gestion d'un fichier aussi volumineux.

J'ai étudié ce fichier et essayé de résoudre les problèmes de syntaxe, pour finalement arriver à la conclusion que je devrais chercher une autre approche.

Mon étape suivante consistait à utiliser la fonction sqlite3 pour exporter un script SQL via le terminal (linux).

Cette fois, le script s'est beaucoup amélioré en termes de syntaxe, mais néanmoins le gros problème est que l'un ou l'autre nouveau problème est toujours apparu.

Les deux approches étant épuisées, j'ai pris un moment pour réfléchir et évaluer d'autres alternatives. J'ai considéré que Python pourrait être un outil efficace pour cette migration, compte tenu de sa prise en charge à la fois de SQLite et de MySQL, et j'ai commencé à concevoir un algorithme pour automatiser le processus.

J'ai donc cherché des informations sur le sujet, vérifiant d'abord qu'il s'agissait d'une approche possible et collectant des informations pour pouvoir concevoir un algorithme qui me permettrait d'atteindre mon objectif.

Je vais maintenant décrire brièvement la nouvelle approche avec laquelle j'ai réussi à atteindre mon objectif.
La première chose que j'ai faite a été de documenter mes recherches étape par étape, ce qui m'a amené à découvrir ce qu'on appelle la cartographie relationnelle-objet (ORM).

Le

cartographie relationnelle objet (ORM) est une technique utilisée en programmation pour convertir des données entre des systèmes de types incompatibles dans des langages de programmation orientés objet. Dans le contexte des bases de données, ORM permet d'interagir avec des bases de données relationnelles via des objets au lieu d'utiliser directement des requêtes SQL. Cela offre une manière plus intuitive et efficace de travailler avec les données.

Dans mon cas, j'ai utilisé SQLAlchemy pour réaliser le développement de l'algorithme en python, et en analysant les résultats, j'ai trouvé les points clés suivants.

• Classes comme les tables :
  • Chaque classe que vous définissez (telle que crime_scene_report, drivers_license, etc.) correspond à une table de la base de données. Les attributs de classe représentent les colonnes du tableau.
• Instances sous forme de lignes :
  • Chaque instance d'une classe représente une ligne dans le tableau correspondant. Lorsque vous interrogez des données depuis SQLite, vous obtenez des instances de ces classes, ce qui rend le travail avec les données plus intuitif et orienté objet.
• Opérations d'insertion et de mise à jour :
  • L'utilisation de méthodes telles que merge() vous permet d'opérer directement sur ces instances. Vous pouvez insérer de nouveaux enregistrements ou mettre à jour des enregistrements existants sans avoir à écrire manuellement des requêtes SQL, ce qui simplifie le code et le rend plus lisible.
• Gestion des relations :
  • SQLAlchemy gère automatiquement les relations entre les tables (par exemple, via des clés étrangères) via des attributs dans les classes, ce qui facilite la navigation entre les enregistrements associés.

Une chose importante à noter au cours du processus, après divers essais et erreurs, est que comprendre l'approche et évaluer le code écrit est crucial, car cela vous aide à identifier les endroits où des problèmes peuvent survenir. Après réflexion et pause, je suis arrivé à la conclusion que le problème était probablement lié à la structure de la base de données. Cependant, une question persistait dans mon esprit : comment est-il possible que cette base de données fonctionne dans SQLite malgré les problèmes d'intégrité et les différentes erreurs qui sont apparues ? La réponse est simple : contrairement à MySQL, SQLite permet d'avoir des tables sans clés primaires, ce qui contribue à de grandes différences dans la gestion des données entre les deux systèmes. Cette flexibilité de SQLite peut masquer des problèmes qui, dans un environnement plus restrictif comme MySQL, entraîneraient des erreurs immédiates.

Une autre différence est que MySQL a une approche plus rigoureuse de la structure et des types de données. Par exemple, si vous définissez un champ comme INTEGER, vous ne pourrez pas insérer une valeur autre qu'un nombre.

Les différences continuent, le résultat de leur compréhension a été de se rendre compte que pour que l'approche fonctionne, il faudrait un changement dans la base de données, pour cela j'ai décidé de modifier les tables et de m'assurer qu'elles étaient conformes aux normes MySQL, le la première chose est que chacun a sa clé primaire, et je m'assure que les deux ont les mêmes types de données.

J'ajoute... Si vous souhaitez faire de même, gardez à l'esprit que SQLite ne vous permet pas de modifier directement les tables, autre grande différence avec MySQL.

Enfin, après avoir fait les adaptations dans le script et dans l'algorithme écrit en python, j'ai procédé à son exécution. Le résultat : la base de données du jeu a été migrée vers MySQL.

Ce défi a non seulement amélioré mes compétences techniques, mais m'a également appris l'importance de comprendre les différences entre les systèmes de gestion de bases de données et comment celles-ci peuvent affecter l'intégrité des bases de données.

J'espère que mon expérience de migration de base de données de SQLite vers MySQL a été utile et inspirante. Chaque défi présente une opportunité d'apprendre et de grandir dans le monde de la programmation.
Merci d'avoir lu et à la prochaine fois !