¿Cuál es la mejor forma de administrar objects SQL "no SQL Server" dentro de Visual Studio 2010?

Visual Studio tiene un proyecto de database para el server Sql. Esto tiene una serie de ventajas: aloja configuraciones de configuration y objects de database en un solo lugar. Los files .sql son parte de las soluciones .NET regulares, visibles en el Explorador de soluciones y editables en Visual Studio. Y tienen un mecanismo para generar una secuencia de commands de implementación. Con cada object de database individual en su propio file, el seguimiento de los cambios y el control de la fuente se simplifica enormemente.

¿Alguien ha tenido éxito con el uso de proyectos de bases de datos con bases de datos "no SQL Server"? Usamos Sybase, que usa T-SQL y es muy similar a SQL Server, así que estoy esperanzado.

¿O hay un enfoque alternativo? Creo que podría usar un proyecto estándar (.csproj) y llamar a una aplicación de command-line personalizada como parte de la compilation posterior para convertir los files .sql en una secuencia de commands de implementación.

Cualquier idea sería bienvenida.

Gracias

OK, responderé mi propia pregunta.

Agregué todos nuestros objects SQL a sus propios files .sql dentro de un proyecto Visual Studio .dbproj. Sin embargo, las incompatibilidades sintácticas menores entre la versión de Sybase de RAISERROR y la versión de RAISERROR de Microsoft provocaron que el código de validation incorporado en Visual Studio no fuera feliz. El problema con el proyecto de la database era que esto realmente causaba un error de compilation, que básicamente lo convertía en un stop-stopper.

Así que descarté esa idea y agregué los files .sql a un file de proyecto .csproj estándar. Luego implementé un código personalizado que cargaría todos los files .sql y los agregaría en una secuencia de commands de implementación cuando se invocara. Agregué una llamada al código personalizado a la compilation posterior del file .csproj para que cada vez que se comstackra, genere un guión de implementación, que funciona como un sueño con nuestro server de compilation.

Para get algunos de los beneficios de .dbproj, busqué escribir un analizador de SQL completo, pero algunas de las publicaciones de SO me desanimaron rápidamente. En cambio, realicé un análisis rudimmental con expresiones regulares, lo que me dio algunas características interesantes sin mucho esfuerzo:

  1. El código podría detectar dependencies entre los diversos files .sql y agregarlos a la secuencia de commands de implementación en el order correcto para evitar advertencias de sysdepends.
  2. Donde no había dependencies, los objects se orderaban según el tipo de object (procedimiento almacenado, function, statement de concesión, etc.) y luego por nombre para que el script resultante siempre se orderara de la misma manera, lo cual es muy importante si necesita diferenciar dos versiones del guion
  3. La secuencia de commands de implementación puede encontrar algunos de los permissions necesarios, por lo que no es necesario que realice un seguimiento de todas las declaraciones de GRANT.
  4. Los procedimientos almacenados que se encuentran en la database pero no en el script se pueden descartar automáticamente, por lo que no es necesario que registre en qué estado se encuentra cada database, solo ejecutamos el script y todo está en el estado correcto.
  5. Tenemos algunos procedimientos almacenados que nuestras testings automatizadas llaman que no deberían implementarse. El código puede detectarlos e includelos en una compilation de debugging y excluirlos en una compilation de versión.
  6. El código personalizado también genera un script diff que determina qué cambios hará el script de deployment en una database y los imprime. Esto permite que la persona que ejecuta el script tenga una idea de lo que hará. Por ejemplo, el script diff podría indicarles que no se realizarán cambios, por lo que no es necesario ejecutar el script de deployment en absoluto, lo que es útil si los guarda iniciando session a las 3am para desconectar una database y tomarla copys de security, etc.

Por lo tanto, el resultado final es que todos mis objects SQL se encuentran en files separados, por lo que es fácil trabajar con ellos en Visual Studio y administrarlos bajo el control de código fuente. Por primera vez desde que comencé este trabajo, puedo ver el historial en control de código fuente y decir qué files se han cambiado (antes teníamos un enorme file .sql con absolutamente todo).