J'ai commencé à coder à la main toutes mes instructions DDL (creates/alter/delete), en les ajoutant à mon .sln en tant que fichiers texte et en utilisant la version normale (en utilisant subversion, mais tout contrôle de révision devrait fonctionner). De cette façon, non seulement je bénéficie de la gestion des versions, mais la mise à jour en direct à partir de dev/stage est le même processus pour le code et la base de données : les balises, les branches, etc. fonctionnent de la même manière.

Sinon, je suis d'accord que redgate est cher si vous n'avez pas d'entreprise qui l'achète pour vous. Si vous pouvez convaincre une entreprise de l'acheter pour vous, cela en vaut vraiment la peine !

Si vous avez une entreprise qui l'achète, Toad de Quest Software intègre ce type de fonctionnalité de gestion. Il s'agit essentiellement d'une opération en deux clics pour comparer deux schémas et générer un script de synchronisation de l'un à l'autre.

Ils ont des éditions pour la plupart des bases de données populaires, y compris bien sûr Sql Server.

Je travaille de la même manière que Karl, en conservant tous mes scripts SQL pour créer et modifier des tables dans un fichier texte que je conserve dans le contrôle de source. En fait, pour éviter le problème d'avoir à faire examiner par un script la base de données en direct pour déterminer quels ALTER exécuter, je travaille généralement comme ceci :

• Sur la première version, je place tout pendant les tests dans un seul script SQL et traite toutes les tables comme un CREATE. Cela signifie que je finis par supprimer et lire beaucoup de tables pendant les tests, mais ce n'est pas un gros problème au début du projet (puisque je suis généralement en train de pirater les données que j'utilise à ce stade de toute façon).
• Sur toutes les versions ultérieures, je fais deux choses : je crée un nouveau fichier texte pour contenir les scripts SQL de mise à niveau, qui contiennent uniquement les ALTER de cette version. Et j'apporte les modifications à l'original, crée également un nouveau script de base de données. De cette façon, une mise à niveau exécute simplement le script de mise à niveau, mais si nous devons recréer la base de données, nous n'avons pas besoin d'exécuter 100 scripts pour y arriver.
• En fonction de la façon dont je déploie les modifications de la base de données, je place également généralement une table de version dans la base de données qui contient la version de la base de données. Ensuite, plutôt que de prendre des décisions humaines sur les scripts à exécuter, le code que j'ai pour exécuter les scripts de création/mise à niveau utilise la version pour déterminer ce qu'il faut exécuter.

La seule chose que cela ne fera pas est d'aider si une partie de ce que vous passez du test à la production est constituée de données, mais si vous voulez gérer la structure et ne pas payer pour un package de gestion de base de données agréable mais coûteux, ce n'est vraiment pas le cas très difficile. J'ai également trouvé que c'était un très bon moyen de garder une trace mentale de votre base de données.

Je suis d'accord que tout scénariser est la meilleure façon de procéder et c'est ce que je préconise au travail. Vous devez tout scripter, de la création de la base de données et de l'objet au remplissage de vos tables de recherche.

Tout ce que vous faites dans l'interface utilisateur ne sera pas traduit (en particulier pour les changements... pas tellement pour les premiers déploiements) et finira par nécessiter un outil comme celui proposé par Redgate.

Comme Rob Allen, j'utilise SQL Compare / Data Compare de Redgate. J'utilise également l'assistant de publication de base de données de Microsoft. J'ai aussi une application console que j'ai écrite en C

Je suis d'accord avec le fait de tout conserver dans le contrôle des sources et de scripter manuellement toutes les modifications. Les modifications apportées au schéma d'une version unique entrent dans un fichier de script créé spécifiquement pour cette version. Toutes les procédures, vues, etc. stockées doivent être placées dans des fichiers individuels et traitées comme .cs ou .aspx en ce qui concerne le contrôle des sources. J'utilise un script powershell pour générer un gros fichier .sql pour mettre à jour les éléments de programmabilité.

Je n'aime pas automatiser l'application des changements de schéma, comme les nouvelles tables, les nouvelles colonnes, etc. Lors d'une version de production, j'aime parcourir le script de modification commande par commande pour m'assurer que chacun fonctionne comme prévu. Il n'y a rien de pire que d'exécuter un gros script de modification en production et d'obtenir des erreurs parce que vous avez oublié un petit détail qui ne s'est pas présenté lors du développement.

J'ai également appris que les index doivent être traités comme des fichiers de code et placés dans le contrôle de code source.

Et vous devriez certainement avoir plus de 2 bases de données - dev et live. Vous devriez avoir une base de données de développement que tout le monde utilise pour les tâches de développement quotidiennes. Ensuite, une base de données intermédiaire qui imite la production et est utilisée pour effectuer vos tests d'intégration. Ensuite, peut-être une copie récente complète de la production (restaurée à partir d'une sauvegarde complète), si cela est possible, de sorte que votre dernière série de tests d'installation va à l'encontre de quelque chose qui est aussi proche que possible de la réalité.

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 :

1. La base de données existe-t-elle ? Sinon, créez-le.
2. 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