¿Alternativas para soluciones y proyectos de SSMS?

De acuerdo con la documentación oficial de SQL Server , el uso de "Soluciones, Proyectos y Elementos" está en desuso. Un banner de advertencia visible (aunque algo críptico) en la parte superior de la página de MSDN dice:

"Esta característica se eliminará en una versión futura de Microsoft SQL Server. Evite usar esta característica en nuevos trabajos de desarrollo y planee modificar las aplicaciones que actualmente usan esta característica".

Desafortunadamente, no se ofrecen sugerencias para estrategias alternativas de almacenamiento / contenedor. Entonces, ¿cuál es la forma recomendada para almacenar y empaquetar los diversos scripts, consultas y archivos que componen su aplicación de base de datos? También me interesaría saber si alguno de ustedes está utilizando realmente el marco de Soluciones o Proyectos en su trabajo actual, y para qué los utilizan.

[Nota: me doy cuenta de que podría usar VS2010 para esta funcionalidad, pero estoy interesado en los enfoques basados ​​en SSMS (por las razones expresadas en la respuesta a esta pregunta ).]

Leyendo entre líneas, supongo que la expectativa / plan era que el tipo de proyecto de Herramientas de datos del servidor SQL (SSDT) ​​se extendiera a SSMS para el lanzamiento de SQL 2012. Evidentemente eso no sucedió, por lo que estamos atrapados con el ( francamente terrible) SSMS interpretación de un proyecto.

Si desea algo para administrar la fuente de su base de datos, debería sumergirse profundamente en SSDT. Actualmente lo estoy usando para un proyecto greenfield y también estoy moviendo una gran base de datos brownfield a él. Pequeñas molestias y puntos débiles, pero no se detienen, y ya estamos recuperando el tiempo invertido.

Jamie Thomson , quien blogueó extensamente sobre Proyectos de base de datos VS2010 (el predecesor), ha comenzado a publicar artículos sobre SSDT y parece ser tan fanático como yo. Bob Beauchemin es otro adoptador temprano que vale la pena seguir.

Si desea organizar una colección de scripts aleatorios (en lugar de una compilación completa de la base de datos) puede hacerlo, pero el soporte no es del todo "de primera clase". Para hacerlo, cree un tipo de proyecto SSDT estándar y cambie sus scripts al tipo de compilación "Ninguno" en las propiedades del archivo.

Aquí en Red Gate acabamos de lanzar una compilación de SQL Source Control que funciona junto con SSDT, proporcionando una forma de administrar y controlar los cambios en la base de datos de SQL Server Management Studio, trabajando en contra del repositorio de proyectos de la base de datos.

Se pueden encontrar más detalles y un enlace de descarga en los foros SSDT:

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

Esta es una compilación Beta gratuita. Actualmente estamos buscando comentarios de la comunidad antes de fusionar esta característica en el lanzamiento completo.