2009-06-16 8 views
5

ATTENTION: LONGUE QUESTION.Comment contrôlez-vous la version et gérez-vous plusieurs branches d'une base de données?

[QUESTION]

Si la stratégie est d'avoir une branche par base de données, comme décrit dans le problème ci-dessous, où les scripts sont sous contrôle de version.

Comment gérez-vous les problèmes de migration de données lorsque vous tentez de consolider vers moins de succursales?
Est-ce que c'est juste un coût que vous encourez dans le cadre de la migration de données?

Les scripts de transformation essentielle devront être créés au moment de la migration.

Y a-t-il un meilleur moyen?
Pouvons-nous résoudre les deux problèmes en même temps?
Quelle est la meilleure pratique?

[CONTEXTE]

A mon lieu de travail que nous avons un produit qui a 3 branches. Mainline ayant les "DERNIERS ET PLUS GRANDS" changements qui ne sont pas nécessaires prêts pour la libération.

  • Version B (les noms ont été changés pour protéger les coupables)
  • Version A (les noms ont été changés pour protéger les coupables)
  • réseau principal

En raison de ces branches, il est effectivement 3 versions de la base de données. Le contrôle de la version du code est relativement simple, mais le contrôle de la version de la base de données semble difficile. Après avoir lu Do you use source control for your database items? , il semble que le meilleur moyen est d'exporter tous les scripts de création pour chaque objet/table. NOTE: La façon dont vous le gérez, dans un grand script ou plusieurs scripts ou hybride, est votre préférence selon l'article. Je suis d'accord avec cela et ai demandé pourquoi ce n'est pas fait.

Actuellement, les administrateurs de base de données refusent de ramifier les scripts dans des branches. En dehors de la paresse comme excuse, la raison est de gagner du temps avec la migration des données. Effectivement, les modifications de la base de données sont maintenues de force dans toutes les versions.

Tous les scripts sont contrôlés par version et conservés uniquement dans la ligne principale. La version A et la version B ont leur propre fichier spécial qui indique les changements de scripts à exécuter sur leur branche respective. Le problème se pose lorsqu'il existe un script de modification, par exemple appliqué à la version A, mais la version B ne nécessite qu'une partie des modifications. Il appartient au développeur d'informer les administrateurs de base de données de mettre à jour le fichier qui indique les correctifs à appliquer pour chaque branche. Pour les scripts de modification qui nécessitent trop d'intervention manuelle, il est nécessaire d'appliquer manuellement une partie du script de modification.

Pour mettre à jour une base de données sur la version A, tous les correctifs sont extraits avec le correctif de la version A à appliquer.

[SCÉNARIO]

  • Les 3 versions ci-dessus existent.
  • Les modifications de base de données se produisent à la version A.
  • Consolidation de branche où le code est fusionné de la version B à A afin que la version B peut être supprimée.
  • La même chose doit se produire avec la base de données.

Espérons que cela a du sens.

+0

Pouvez-vous préciser si l'un de vos scripts de base de données est ACTUELLEMENT contrôlé par la version? Ou envisagez-vous d'utiliser le contrôle des sources à l'avenir pour gérer plusieurs branches de votre base de données? En outre, votre question sur la façon de fusionner les bases de données fréquemment ou seulement une fois pour se débarrasser complètement des branches est-elle également? –

+0

J'ai clarifié ce que le problème est ci-dessus. On dirait que la stratégie de contrôle de version en place est seulement parce que le branchement doit être évité, pour des raisons que je ne peux pas comprendre. Je pensais que ma compréhension du problème était parce qu'il y avait un gros coût avec la migration des données. Mais comme John Saunders l'indique ci-dessous, il est généralement pris en compte lorsque les scripts de modification sont créés en premier lieu. Merci les gars pour votre aide. On dirait que les stratégies normales de contrôle de version fonctionneraient après tout. –

Répondre

3

Jetez un oeil à Chapter 8 dans Eric Sink's Source Control HOW TO. C'est une excellente ressource pour comprendre les tenants et les aboutissants du contrôle de la source.

+0

nikmd23, Merci pour le lien. La fusion de contrôle de source est en effet comme vous l'avez référencé. Toutefois, que se passe-t-il si plusieurs modifications de base de données ont eu lieu et si les modifications de script sont correctement fusionnées entre les branches. Est-ce juste un coût que la personne affectée à consolider les changements, disons des mois plus tard, intervient dans le temps qu'ils doivent investir dans l'écriture des scripts de transformation etc. Le problème n'est pas le contrôle du script de la base de données le problème est la migration des données . Est-ce qu'il y a loin? Par exemple, maintenir un script pour chaque changement de migration de données? Ai-je manqué quelque chose? –

+1

Chaque modification de schéma doit prendre en compte la migration des données. Parfois, les modifications du schéma ne nécessitent aucun changement dans les données. Parfois, ils nécessiteront des changements dans les données. Dans ce cas, il appartient à ces scripts de modifier également les données, mais cela peut être nécessaire. –

Questions connexes