Alternatives pour les solutions et projets SSMS?

Selon la documentation officielle de SQL Server , l'utilisation de «Solutions, projets et éléments» est déconseillée. Une bannière d'avertissement bien visible (quoique quelque peu cryptique) en haut de la page MSDN indique:

"Cette fonctionnalité sera supprimée dans une future version de Microsoft SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité."

Malheureusement, aucune suggestion de stratégies alternatives de stockage / conteneur n'est proposée. Alors, quelle est la méthode recommandée pour stocker et empaqueter les divers scripts, requêtes et fichiers qui composent votre application de base de données? Je serais également très intéressé de savoir si certains d'entre vous utilisent réellement le cadre Solutions ou Projets dans votre travail actuel, et pourquoi vous les utilisez.

[Remarque: je me rends compte que je pourrais utiliser VS2010 pour cette fonctionnalité, mais je suis intéressé par les approches basées sur SSMS (pour les raisons exprimées dans la réponse à cette question ).]

En lisant entre les lignes, je suppose que l'attente / le plan était que le type de projet SQL Server Data Tools (SSDT) ​​soit étendu à SSMS pour la version de SQL 2012. Évidemment, cela ne s'est pas produit, nous sommes donc coincés avec le ( franchement épouvantable) Interprétation SSMS d'un projet.

Si vous voulez que quelque chose gère votre source de base de données, vous devriez plonger profondément dans SSDT. Je l'utilise actuellement pour un projet greenfield et je lui transfère également une grande base de données brownfield. Niggles mineurs et points douloureux mais pas de bouchons d'exposition et nous récupérons déjà le temps investi.

Jamie Thomson , qui a beaucoup blogué sur VS2010 Database Projects (le prédécesseur), a commencé à publier des articles sur SSDT et semble être un grand fan comme moi. Bob Beauchemin est un autre premier adopteur à suivre.

Si vous voulez organiser une collection de scripts aléatoires (plutôt qu'une compilation complète de base de données), vous pouvez mais le support n'est pas tout à fait "de première classe". Pour ce faire, créez un type de projet SSDT standard et modifiez vos scripts en type de compilation "Aucun" dans les propriétés du fichier.

Chez Red Gate, nous venons de publier une version de SQL Source Control qui fonctionne avec SSDT, offrant un moyen de gérer et de contrôler les modifications de la base de données à partir de SQL Server Management Studio, en travaillant avec le référentiel de projet de base de données.

Plus de détails et un lien de téléchargement peuvent être trouvés sur les forums SSDT eux-mêmes:

http://social.msdn.microsoft.com/Forums/en-GB/ssdt/thread/0c763f98-c55a-44a7-9100-80a6d9223d04

Il s'agit d'une version bêta gratuite. Nous recherchons actuellement les commentaires de la communauté avant de fusionner cette fonctionnalité dans la version complète.