Mysql
 sql >> Base de données >  >> RDS >> Mysql

Commencer par versionner les schémas mysql sans excès. Bonne solution ?

Un moyen simple pour une petite entreprise :videz votre base de données vers SQL et ajoutez-la à votre référentiel. Ensuite, chaque fois que vous modifiez quelque chose, ajoutez les modifications dans le fichier de vidage.

Vous pouvez ensuite utiliser diff pour voir les changements entre les versions, sans parler d'avoir des commentaires expliquant vos changements. Cela vous rendra également pratiquement immunisé contre les mises à jour de MySQL.

Le seul inconvénient que j'ai constaté est que vous devez vous rappeler d'ajouter manuellement le SQL à votre fichier de vidage. Vous pouvez vous entraîner à toujours vous souvenir, mais soyez prudent si vous travaillez avec d'autres. Manquer une mise à jour pourrait être pénible plus tard.

Cela pourrait être atténué en créant un script élaboré pour le faire pour vous lors de la soumission à subversion, mais c'est un peu trop pour un one man show.

Modifier : Au cours de l'année qui s'est écoulée depuis cette réponse, j'ai dû implémenter un schéma de gestion des versions pour MySQL pour une petite équipe. L'ajout manuel de chaque modification était considéré comme une solution fastidieuse, un peu comme cela a été mentionné dans les commentaires, nous avons donc décidé de vider la base de données et d'ajouter ce fichier au contrôle de version.

Ce que nous avons découvert, c'est que les données de test se retrouvaient dans le vidage et qu'il était assez difficile de comprendre ce qui avait changé. Cela pouvait être résolu en vidant uniquement le schéma, mais cela était impossible pour nos projets car nos applications dépendaient de certaines données de la base de données pour fonctionner. Finalement, nous sommes revenus à l'ajout manuel de modifications dans le vidage de la base de données.

Non seulement c'était la solution la plus simple, mais cela résolvait également certains problèmes rencontrés par certaines versions de MySQL lors de l'exportation/importation. Normalement, nous devrions vider la base de données de développement, supprimer toutes les données de test, les entrées de journal, etc., supprimer/modifier certains noms le cas échéant et seulement ensuite être en mesure de créer la base de données de production. En ajoutant manuellement des modifications, nous pouvions contrôler exactement ce qui se retrouverait en production, petit à petit, afin qu'à la fin tout soit prêt et que le passage à l'environnement de production soit aussi simple que possible.