Ceci a été un gros point d'interrogation dans mon esprit.
Je déménage sur Mercurial ou Git très bientôt pour mon logiciel Web, et parfois, mes branches nécessitent des changements de base de données importants que les autres branches ne devraient pas voir. Cela, je ne peux pas toujours partager la même base de données pour mes succursales.
Y a-t-il une manière standard de traiter des changements de base de données pour la ramification et le clonage? Que faites vous tous? J'utilise MySQL.
4 Réponses :
Pour la manipulation du clonage, votre base de données doit être conçue pour être multi-utilisateurs.
Pour les changements de schéma, engagez des modifications au schéma de cette branche dans le cadre du respectoire.
Ensuite, vous devez vous décider, pour chaque schéma, exécutez-vous plusieurs espaces de table dans une base de données, plusieurs bases de données, etc.? Ensuite, commettez un pointeur à la bonne dans le cadre de la configuration d'installation dans cette branche.
Qu'entendez-vous par un pointeur? Parlez-vous de changer le DSN pour chaque branche?
Qu'entendez-vous par "conçu pour être multi-utilisateur?" Voulez-vous dire si chaque développeur a une succursale, cela devrait fonctionner pour chacune de ces branches?
Un clone du repo est juste que, un clone identique, complet avec des branches internes. Si la préoccupation est la gestion du clonage, alors (je suppose) la préoccupation est que plusieurs développeurs accéderont à une base de données à la fois, ou un développeur unique avec plusieurs référentiels clonés accédera à la base de données à partir de plusieurs copies de l'application en cours d'exécution. Pour cette seule instance, ignorez les branches, si vos bases de données sont multi-utilisateurs, la manipulation des référentiels clonés est pris en charge.
J'ai utilisé le terme "pointeur" vague, car la nature du pointeur dépend de la nature de votre solution. Si vous utilisez plusieurs espaces de table dans une base de données, ils pourraient tous partager le même DSN. Si vous utilisez plusieurs bases de données, vous pouvez basculer entre eux à l'aide du DSN.
Je n'ai pas de réponse pour vous, mais j'ai rencontré un article récent qui pourrait être pertinent: Pourquoi votre stratégie de contrôle de la version de base de données est cycle et quoi faire à ce sujet, partie I
Utiliser un outil de base de données Changset peut être vraiment utile. J'ai utilisé Liquibase ( http://www.liquibase.org ), au travail pour gérer le contrôle de la version pour le dB. Je recommanderais chaleureusement cet outil à quiconque. Liquibase prend des modifications de support, avec des scénarios de restauration configurables. Cependant, il s'agit d'un outil de gestion du schéma, pas des données réelles. Je n'essaierais pas de l'utiliser pour garder les données de la table à jour.
Cependant, je pense toujours que votre meilleur pari est d'utiliser Liquibase et d'avoir des schémas différents, pour différentes branches de sources.
Était-il facile de résoudre les conflits de fusion dans le changelog? At-il une solution intégrée pour les caisses?
Le schéma de base de données est lui-même (enregistré dans) une base de données dont la structure est, plus ou moins, définie par l'information_schema de la norme SQL.
Maintenant, les DBMS sont conçus de manière assez délibérément pour ne laisser qu'une seule valeur de base de données à un seul point à temps. Et puisque le catalogue est lui-même "juste une valeur de base de données pour la base de données INFORMATION_SCHEMA", support SQL Systems, sans délibérément, une seule structure de base de données à un seul point à l'autre.