Quelle est la meilleure façon de contrôler la version de mes objets de base de données? J'utilise Visual studio 2005/2008 et SQL Server 2005. Je préférerais une solution utilisable avec SVN.
Identique à votre autre code, ajoutez un "projet de base de données" à votre solution d'application et conservez-y les fichiers sql utilisés pour construire les objets de base de données. Utilisez le même contrôle de version pour ces fichiers de code que pour l'application.
Regardez les outils offerts par RedGate. Ils traitent spécifiquement des cas de sauvegarde/restauration/comparaison pour les objets SQL Server, y compris les SP. Alternativement, je ne suis pas sûr, mais je pense que Visual Studio vous permet de vérifier les sp dans un référentiel. Havent a essayé moi-même. Mais je peux recommander les outils RedGate. Ils m'ont sauvé une tonne de problèmes
J'utilise SVN pour tout mon contrôle de source de table/sproc/fonction.
Je n'ai rien trouvé qui réponde à mes besoins, j'ai donc fini par écrire un tilitaire pour me permettre de vider le code dans une structure de répertoire agréable à utiliser avec SVN.
Pour les personnes intéressées, la source est maintenant disponible sur svn: //finsel.com/public/VS2005/GenerateSVNFilesForSQL2005 .
Nous utilisons Subversion et tout ce que nous faisons est d'enregistrer le code sql dans le répertoire de notre projet Subversion, puis de valider le code dans le référentiel lorsque nous sommes prêts et de le mettre à jour à partir du référentiel avant de commencer à travailler sur quelque chose qui s'y trouve déjà.
Le vrai truc est de convaincre les développeurs de le faire. Nos dbas le font en supprimant tout proc stocké (ou tout autre objet de base de données) qui n'est pas dans Subversion périodiquement. Perdez des trucs une fois et à peu près personne ne recommence.
Le meilleur moyen - celui qui fonctionne pour vous.
Manière la plus simple - celle qui n'existe pas actuellement.
Nous utilisons une méthode semi-manuelle (scripts sous contrôle de code source, petit sous-ensemble de personnes capables de déployer des procédures stockées sur le serveur de production, les modifications du schéma devraient reflété dans les modifications apportées aux fichiers sous-jacents enregistrés).
Ce que nous devrions faire, c'est implémenter une sorte de contrôle de source vs diff de vidage de schéma en clair ... mais cela "fonctionne pour nous" généralement bien que ce soit vraiment un problème la plupart du temps.
Je ne connais pas de solution préemballée, désolé ...
... mais ne pourriez-vous pas juste un petit script qui se connecte à la base de données et enregistre toutes les procédures stockées sur le disque sous forme de fichiers texte? Ensuite, le script ajouterait tous les fichiers texte au référentiel SVN en faisant un appel système à "svn add".
Ensuite, vous souhaitez probablement qu'un autre script se connecte à la base de données, supprime toutes les procédures stockées et charge toutes les procédures stockées du référentiel à partir du disque. Ce script devrait être exécuté à chaque fois que vous exécutez "svn up" et que vous avez des procédures stockées nouvelles/modifiées.
Je ne sais pas si cela peut être accompli avec MS SQL, mais je suis assez confiant que MySQL accepterait cela. Si écrire des extensions SVN pour ce faire est trop compliqué, Capistrano supporte les scripts de checkin/checkout, IIRC.
Je suis d'accord que si possible, vous devez utiliser des projets de base de données pour versionner votre base de données avec la source de votre application.
Cependant, si vous êtes dans un scénario d'entreprise, vous devez également envisager d'utiliser un outil pour suivre les modifications sur le serveur et versionner ces modifications. Le fait que le projet de base de données existe ne signifie pas qu'un administrateur ou un développeur ne peut pas modifier ces sprocs sur le serveur.
Utilisez versaplex pour vider votre schéma: http://code.google.com/p/versaplex/
Versaplex est livré avec Schemamatic, qui lit le schéma de la base de données (tables, SP, etc.) ainsi que les données (les données sont exportées au format CSV). Je l'utilise, avec SVN et git, et c'est génial :) Si vous avez besoin d'aide faites le moi savoir, ça vaut le coup d'essayer! http://github.com/eduardok/versaplex
J'utilise scriptdb.exe de http://scriptdb.codeplex.com/
Et il pourrait être utile d'utiliser la méthode Rails: http://code.google.com/p/migratordotnet/wiki/GettingStarted
Nous effectuons des vidages en texte brut et les conservons dans notre VCS.
Vous seriez en mesure de créer un script de sauvegarde et de validation pour faire quelque chose de similaire.