Je fais toute ma création de base de données en tant que DDL, puis encapsule ce DDL dans une classe de maintenance de schéma. Je peux faire diverses choses pour créer le DDL en premier lieu, mais fondamentalement, je fais tout le schéma en code. Cela signifie également que si l'on a besoin de faire des choses non DDL qui ne correspondent pas bien au SQL, vous pouvez écrire une logique procédurale et l'exécuter entre des blocs de DDL/DML.
Ma base de données a alors une table qui définit la version actuelle afin que l'on puisse coder un ensemble de tests relativement simple :
- La base de données existe-t-elle ? Sinon, créez-le.
- La base de données est-elle la version actuelle ? Si ce n'est pas le cas, exécutez les méthodes, dans l'ordre, qui mettent le schéma à jour (vous pouvez inviter l'utilisateur à confirmer et, idéalement, effectuer des sauvegardes à ce stade).
Pour une application mono-utilisateur, je l'exécute simplement sur place, pour une application Web, nous verrouillons actuellement l'utilisateur si les versions ne correspondent pas et avons une application de gestion de schéma autonome que nous exécutons. Pour le multi-utilisateur, cela dépendra de l'environnement particulier.
L'avantage ? Eh bien, j'ai un très haut niveau de confiance que le schéma des applications qui utilisent cette méthodologie est cohérent dans toutes les instances de ces applications. Ce n'est pas parfait, il y a des problèmes, mais ça marche...
Il y a quelques problèmes lors du développement dans un environnement d'équipe, mais c'est plus ou moins évident de toute façon !
Murph