Comment maintenez-vous le contrôle des révisions de la structure de votre base de données?

Question

Quelle est la manière la plus simple de suivre les modifications apportées à une structure de base de données de projets? Lorsque je change quelque chose à propos de la base de données (par exemple, ajouter une nouvelle table, ajouter un nouveau champ à une table existante, ajouter un index, etc.), je veux que cela soit propagé au reste de l'équipe, et finalement serveur de production, avec le minimum d'effort et d'effort. À l'heure actuelle, la solution est assez faible et repose sur des gens qui se souviennent de faire des choses, ce qui est un accident qui attend de se produire.

Tout le reste est géré avec un logiciel de contrôle de révision standard (Perforce dans notre cas).

Nous utilisons MySQL, donc des outils qui comprennent cela seraient utiles, bien que je serais également intéressé d'apprendre comment d'autres endroits gèrent ça de toute façon, quel que soit le moteur de base de données.

Answer 1

Vous pouvez vider le schéma et le valider - et RCS prendra en charge les modifications entre les versions.

Answer 2

Vous pouvez obtenir un outil comme Sql Compare de Red-Gate qui vous permet de pointer vers deux bases de données et il vous permettra de savoir ce qui est différent, et construira des scripts alt pour vous.

Si vous utilisez .NET (Visual Studio), vous pouvez créer un projet de base de données et le vérifier dans le contrôle de source.

Answer 3

Cela a déjà été discuté beaucoup je pense. En tout cas, j'aime beaucoup l'approche de Rails. Il est le code qui a trois choses:

1. Le numéro de version
2. La façon d'appliquer les modifications (mise à jour d'une table de version)
3. La façon de rouler les modifications dans (définit la version sur la table de version Le précédent

Ainsi, chaque fois que vous créez un ensemble de modifications, vous créez ce fichier de code qui peut restaurer ou mettre à niveau le schéma de base de données lorsque vous l'exécutez. Ceci, étant le code, vous pouvez valider dans n'importe quel système de contrôle de révision. Vous validez le premier vidage, puis les scripts uniquement.

La grande chose au sujet de cette approche est que vous pouvez facilement distribuer la base de données des changements aux clients, alors qu'avec une norme décharge juste le schéma et mettre à jour l'approche génère un script de mise à niveau/rollback est une nuisance

Answer 4

Dans mon entreprise chaque développeur est encouragé à enregistrer toutes les modifications de la structure db dans un fichier de script dans le dossier contenant le numéro de révision du module. Ces scripts sont conservés dans le dépôt svn. Lorsque l'application démarre, le code de mise à niveau db compare la version db actuelle et la version de code et si le code est plus récent - se penche sur le dossier scripts et applique automatiquement tous les changements de base de données. De cette façon, chaque instance d'application (sur les machines de production ou de développement) met toujours à jour la base de données vers leur version de code et cela fonctionne très bien.

Bien sûr, une automatisation pourrait être ajoutée - si nous trouvons un outil approprié.

Answer 5

Un mauvais contrôle de version Mans:

fichier séparé pour chaque objet (table, vue, etc.)

Lors de la modification des tables, vous voulez diff CREATE TABLE CREATE TABLE. L'historique du code source est pour communiquer une histoire. Vous ne pouvez pas faire une différence significative de CREATE TABLE et ALTER TABLE

Essayez d'apporter des modifications aux fichiers, puis validez-les dans le contrôle source, puis validez-les dans la base de données SQL. La plupart des outils ne prennent pas cela en charge car vous ne devez pas valider le contrôle de la source tant que vous ne testez pas et vous ne pouvez pas tester sans mettre le code en SQL. Donc, en pratique, vous essayez d'utiliser SQL Redgate pour comparer vos fichiers à la base de données SQL. A défaut, vous adoptez une politique sévère consistant à tout laisser tomber dans la base de données et à le remplacer par ce qui en a fait le contrôle de la source. Les scripts de modification sont généralement à usage unique, mais des applications existent, comme wordpress, où vous devez déplacer le schéma de 1.0 à 1.1, 1.1 à 1.5, etc. Chacun de ces scripts doit être sous contrôle de source et modifié en tant que tel (par ex. comme vous trouvez des bogues dans le script qui vous déplace de 1.0 à 1.1, vous créez une nouvelle version de ce script, pas encore un autre script)