Contrôle de source de base de données vs.scripts de changement de schéma

Question

Construire et maintenir une base de données qui est ensuite déployée/développée davantage par de nombreux développeurs est quelque chose qui se produit tout le temps dans le développement de logiciels.Nous créons un script de construction et maintenons d'autres scripts de mise à jour qui sont appliqués à mesure que la base de données se développe au fil du temps.Il existe de nombreuses façons de gérer cela, des mises à jour manuelles aux applications de console/scripts de construction qui aident à automatiser ces processus.

Quelqu'un ayant construit/géré ces processus est-il passé à une solution de contrôle de code source pour la gestion des schémas de base de données ?Si oui, quelle est la meilleure solution qu’ils ont trouvée ?Y a-t-il des pièges à éviter ?

Red Gate semble être un acteur majeur dans le monde MSSQL et leur contrôle de source DB semble très intéressant :http://www.red-gate.com/products/solutions_for_sql/database_version_control.htm

Bien qu'il ne semble pas qu'il remplace le processus de gestion des données* (par défaut), il ne remplace donc que la moitié du processus de gestion des changements de mon point de vue.

(quand je parle de données, je veux dire des valeurs de recherche et ce genre de choses, des données qui doivent être déployées par défaut ou dans un scénario DR)

Nous travaillons dans un environnement .Net/MSSQL, mais je suis sûr que le principe est le même dans toutes les langues.

Answer 1

Questions similaires

Une ou plusieurs de ces questions existantes pourraient être utiles:

• Le meilleur moyen de gérer les modifications de la base de données
• Changement de base de données MySQL
• Base de données SQL Server Modifier les meilleures pratiques de Workflow
• Vérifiez les modifications de la base de données (contrôle de la version)
• Transfert de modifications d'un DB DB à une production DB
• changements de suivi effectués dans la structure de base de données

ou une recherche de Changement de base de données

Answer 2

Je m'occupe d'un entrepôt de données développé en interne par la banque où je travaille.Cela nécessite une mise à jour constante et nous avons une équipe de 2 à 4 développeurs qui y travaillent.

Nous avons de la chance car il n'existe qu'une seule instance de notre "produit", nous n'avons donc pas à prendre en charge le déploiement sur plusieurs instances qui peuvent être dans des versions différentes.

Nous conservons un fichier script de création pour chaque objet (table, vue, index, procédure stockée, trigger) dans la base de données.

Nous évitons l'utilisation de ALTER TABLE dans la mesure du possible, préférant renommer une table, créer une nouvelle et migrer les données.Cela signifie que nous n'avons pas besoin de parcourir une histoire de ALTER scripts - nous pouvons toujours voir la version à jour de chaque table en consultant son script de création.La migration est effectuée par un script de migration distinct - celui-ci peut être en partie généré automatiquement.

Chaque fois que nous effectuons une version, nous avons un script qui exécute les scripts de création/de migration dans l'ordre approprié.

POUR VOTRE INFORMATION:Nous utilisons Visual SourceSafe (beurk !) pour le contrôle du code source.

Answer 3

Je cherche un outil de contrôle de source SQL Server - et je suis apparu à de nombreuses versions premium qui font le travail - à l'aide du studio SQL Server Management en tant que plugin.

Liquibase est libre mais je ne l'ai jamais tout à fait de travailler pour mes besoins.

Il existe un autre produit libre, ce qui fonctionne bien que cela se tient à partir de SSMS et de scripts d'objets et de données au fichier plat.

Ces objets peuvent ensuite être pompés dans une nouvelle instance SQL Server qui recréera ensuite les objets de base de données.

voir gitsql

Answer 4

Peut-être que vous demandez Liquibase ?