Quel est votre processus pour faire face aux changements de schéma de base de données dans une équipe de développement?

Question

ici est une question plus générale sur la façon dont vous gérez les modifications du schéma de base de données dans une équipe de développement.

Nous sommes une équipe de développeurs et les bases de données utilisées au cours du développement local courons sur la boîte de tout le monde que nous voulons éviter l'obligation d'avoir accès à Internet tout le temps. Il faut donc lancer une seule instance de base de données centrale est quelque part pas une option réelle.

Chaque fois que l'un d'entre nous décide qu'il est temps d'étendre / modifier le schéma db, nous envoyons les fichiers de base de données (MYI / MYD) ou des fichiers SQL pour exécuter autour, ou donner des instructions autres au téléphone ce qu'ils doivent faire pour obtenir le code a changé en cours d'exécution sur leurs blocs de données locales. Ce n'est pas l'approche parfaite pour vous. Le même problème se pose lorsque nous avons besoin d'ajuster le schéma de base de données sur la mise en scène ou à la production une fois une nouvelle version est prêt.

Je me demandais comment les gars ... traitez-vous ce genre de choses? Pour le code source, nous utilisons SVN.

apprécie vraiment vos commentaires!

Merci, Michael

Answer 1

Une approche que nous avons utilisé dans le passé est de scripter l'ensemble de la base de données DDL, ainsi que toutes les données de test / configuration nécessaires. Magasin qui dans SVN, puis quand il y a un changement, tout développeur peut tirer vers le bas les changements, laissez tomber la base de données, et le reconstruire à partir des fichiers de script.

Answer 2

À tout le moins vous devriez avoir les scripts de tous les objets dans la base de données (tables, procédures stockées, etc.) sous contrôle de source.

Je ne pense pas que les modifications du schéma de diffusion est une véritable option pour une équipe de développement professionnel.

Answer 3

Nous avions un système sur l'une de mes équipes précédentes qui était le meilleur que je l'ai rencontré pour faire face à cette situation.

La nightly build de l'application comprend une construction d'une base de données (SQL Server). La base de données se est construit sur le serveur de test DB. Chaque développeur avait alors un package DTS (ce qui était il y a un certain temps, et je suis sûr qu'ils mis à niveau vers des packages SSIS) pour tirer vers le bas que construire DB nuit à leur environnement DB local.

a gardé la copie de maître dans un endroit et de mettre le fardeau sur les développeurs de leurs bases de données de dev frais locaux.

Answer 4

A mon travail, nous traitons avec des bases de données assez grandes qui sont de temps pour générer, donc pour nous, à partir de zéro avec un nouveau DB n'est pas idéal. Comme Harper, nous avons notre DDL dans SVN. De plus, nous enregistrons un numéro de version dans une table de base de données. Chaque contrôle en qui change la DB doit être accompagnée d'un script:

1. modernisera le schéma de base de données et modifier les données existantes de façon appropriée et
2. mettra à jour le numéro de version dans la base de données.

De plus, nous comptons les scripts et les versions de base de données telles qu'un script que nous avons écrit sait comment améliorer encore le long d'une branche ou d'une branche plus à une plus récente sans entrée du développeur (à l'exception du nom de base de données et le répertoire des scripts de mise à niveau).

Ainsi, si j'ai une copie de 4 Go DB d'un client qui est d'une année ancienne version et je veux tester la façon dont leurs données fonctionneront avec la version nous avons coupé hier, je peux exécuter notre script et laissez-le gérer les mises à niveau plutôt que de devoir repartir à zéro et refaire tous les INSERT, UPDATE et DELETE effectué depuis la base de données a été créée.

Answer 5

Nous avons une description non-SQL du schéma de base de données. Lorsque l'application démarre, il compare le schéma de base de données désirée avec le schéma de base de données réelle, et Réalise toutes les TABLE ADD, Ajouter une colonne, ADD INDEX, déclarations, etc., il a besoin de faire pour obtenir la base de données de regarder à droite.

Cela ne gère pas tous les cas; parfois, vous devez supprimer la base de données et de recréer si si vous avez changé quelque chose que le résolveur de schéma ne peut pas gérer, mais la plupart du temps, nous ne devons pas inquiéter.

Answer 6

Je serais certainement garder le schéma de base de données dans le contrôle de code source.

A mon emploi actuel, chaque fois qu'il ya un changement de schéma, nous écrivons le SQL pour le changement (alter table xyz ajouter la colonne ...) et le mettre dans SVN. Ensuite, les développeurs peuvent mettre à jour les bases de données de test en exécutant ce script. Il est assez maladroit, mais cela fonctionne.

Lors d'un emploi précédent, j'ai écrit un code qui démarrage à l'application comparerait automatiquement le schéma de base de données réelle à ce qu'elle attendait, et si elle n'a pas été à ce jour les mises à jour exécutée de. La plupart du temps cela a été fait pour des raisons de déploiement: Lorsque nous avons livré de nouvelles copies du logiciel, il serait alors automatiquement mettre à jour la base de données de l'utilisateur. Mais il était également très pratique pour les développeurs.

Je pense qu'il devrait y avoir un outil SQL générique pour le faire. Peut-être, mais je ne l'ai jamais vu.