J'ai beaucoup réfléchi et lu sur ce sujet. Il s'agit d'un vaste sujet de contrôle de configuration et de stratégie de gestion des changements. CMMI a un domaine dans cette rubrique. Même dans les entreprises qui ont une accréditation CMMI 3-5, elles ne contrôlent parfois pas la version de leurs bases de données.
Il convient de répondre à cette question tout en gardant à l'esprit les contraintes suivantes .
- Vous avez un gardien et chaque DDL est exécuté par ce gardien.
- D'autres personnes ont la possibilité d'exécuter des instructions DDL.
- Il vous suffit de consigner les modifications apportées, mais vous n'avez pas besoin de comparer de grandes différences.
- La conception de votre base de données se fait via un outil externe puis est publiée dans la base de données. Cet outil externe peut même être des scripts DDL dans le contrôle de code source. Mais le point clé est que vous le contrôlez à la source, puis le publiez dans la base de données.
- Vous n'avez pas besoin de connaître les changements instantanés mais de temps en temps: c'est-à-dire toutes les heures, tous les jours.
- Vous avez une structure de serveur définie: Développement, Test, Production. Et une bonne stratégie de test.
Réponse 1
- si 1, 4,6 est vrai, vous pouvez utiliser un contrôle de source externe. Par exemple
- Embercadero dispose d'un outil de gestion des modifications de base de données ( http://www.embarcadero.com/products/db-change-manager-xe ). Qui a la capacité de désosser une base de données (Oracle) et de la mettre dans leur contrôle de source. Ensuite, n'importe quel nombre de développeurs, dba peut accéder à ce schéma et y apporter des modifications.
- Oracle SQL Designer est similaire à cette approche.
- Mettre vous créez des scripts de table pour le contrôle de code source (svn, mercurial, etc.) et les maintenir également la même chose.
- http://www.liquibase.org est une approche automatisée ci-dessus.
- J'ai écrit un générateur de code qui a généré des instructions DAL (Data Access Layer), DDL (Create Table). Nous leur avons mis le contrôle des sources et y avons maintenu. Je pense qu'une solution dédiée comme liquibase pourrait mieux fonctionner.
Cette approche fonctionne bien si vous en avez 6. Vous mettez des instructions DDL, qui est également un code, dans le contrôle de code source et le maintenez. Personne ne changera les serveurs de test et de production sans considération.
Les inconvénients sont si vous apportez des modifications aux serveurs de production ou de test pour une raison quelconque, une correction rapide de bogue, un changement de clé primaire, etc. Vous devez également appliquer ces modifications au serveur de développement. Puisqu'en fait, le serveur de développement est votre VÉRITÉ À LA TERRE. Pas l'inverse.
Il s'agit d'une approche très orientée développeur. Mais lorsque vous développez un nouveau module pour la première fois, cela fonctionne plutôt bien.
Réponse 2
- si 1 et 6 sont vrais:
Une approche similaire à la réponse 1 consiste à maintenir un serveur de développement. Tout le monde l'utilise le change. Que le moment de la mise à jour. Vous utilisez un outil de comparaison de base de données. Obtenez-les en tant que scripts, mettez-les sous contrôle de source.
- Red Gate Schema Compare supports Oracle
- Embercadero has similar tool
- https://github.com/carbonfive/db-migration
- http://www.sumsoftsolutions.com/svco/ (I have not used this product but I believe it belongs to this category.)
- Rails Active Migration (http://www.oracle.com/technetwork/articles/kern-rails-migrations-100756.html)
La différence entre la réponse 1 et la réponse 2 est que, dans la réponse 1, vous collectez des instructions DDL pour la base de données entière et vous les stockez. Dans la réponse 2, vous devez stocker chaque version du changement.
- Début
- V1
- V2
- V3
- ...
Si vous mettez une colonne dans une table et décidez plus tard de la supprimer. Vos scripts le montreront dans la réponse2 tandis que dans la réponse1, vous ne verrez que la dernière version. Et vous devez comparer V2 et V1 pour voir les différences. Personnellement, j'aime mieux la réponse 1 car je peux facilement comparer Start et V3, V1 et V3. Dans la réponse 2, je dois rechercher toutes les modifications. Également dans la réponse 2, le script dans le contrôle des sources a tendance à être un script complexe et complexe. Difficile de trouver des informations.
Réponse 3
Si 3 est vrai. Notez que dans cette situation, vous n'avez pas de contrainte 6, c'est-à-dire que vous n'avez pas de serveurs de développement, de test et de produit. Seul serveur de production. Vous pouvez utiliser des déclencheurs DDL pour consigner les modifications apportées. Ceci est principalement utilisé pour décourager les gens d'abuser de leurs subventions DDL. En cas de problème, vous pouvez trouver responsable. Pour que cela fonctionne, chaque personne doit se connecter avec son compte d'utilisateur et le compte d'application ne doit pas avoir de droits DDL. Étant donné que chaque développeur connaît le compte d'application et peut l'utiliser.
Réponse 4
Si vous avez 3 et 5. Notez que dans cette situation, vous n'avez pas de contrainte 6, c'est-à-dire que vous n'avez pas de serveurs de développement, de test et de produit. Seul serveur de production. Au lieu de déclencheur pour stocker les modifications. Vous utilisez un outil externe pour rechercher des modifications et stocker des scripts DDL dans le contrôle de code source.
Si ces outils ont la capacité d'enregistrer qui a fait des changements, ce serait utile. Notez que dans cette solution, vous perdez des DDL supplémentaires qui sont effectués à intervalles.