Compilación condicional del procedimiento almacenado de SQL Server

Versión corta: ¿hay alguna forma de compilar condicionalmente fragmentos de código TSQL en un proyecto de datos de SQL Server utilizando las herramientas de datos de SQL Server para Visual Studio 2010?

Estoy usando las herramientas de datos de SQL Server en Visual Studio 2010 para trabajar en una base de datos experimental de SQL Server Express. El destino final si las cosas funcionan bien sería una plataforma de SQL Server empresarial. Tengo una instancia de 2008 en una caja y una instancia de 2012 en otra, porque mi empresa también está migrando de 2008 a 2012 para las muchas bases de datos empresariales.

En otros lenguajes de programación que he usado, las directivas de preprocesador facilitan la compilación condicional de partes de una base de código. Los usos más comunes para esto son tener diferentes códigos para diferentes plataformas en secciones restringidas o excluir el código de salida de depuración de las versiones de lanzamiento .

Ambos pueden ser muy útiles en algunos procedimientos de la tienda en los que estoy trabajando. ¿Hay algo como esto disponible? Sé que puedo usar sqlcmdvariables para intercambiar valores específicos durante la implementación, pero no puedo entender cómo usar eso para incluir o excluir fragmentos de código posteriores.

Ejemplo:

#IF $(DebugVersion) = 'True'
    -- A bunch of useful PRINTs and what not
#ELSE
    SET NOCOUNT ON
#ENDIF

#IF $(SSVersion) = '2012'
    SET @pretty_date = FORMAT(@some_date, 'dddd, MMM dd, yyyy')
#ELSE
    SET @pretty_date = CAST(@some_date AS nvarchar(12))
#ENDIF

Desafortunadamente, no estoy al tanto de que esto sea posible con SSDT.

Dependiendo de qué tan grande es el proyecto y cuántos procedimientos tiene la intención de mejorar con los regalos de 2012, puede ser manejable con Proyectos Compuestos .

SSDT puede combinar un proyecto de base de datos con uno o más proyectos de bases de datos o dacpacs referenciados para describir un único esquema de base de datos compuesto. El uso de un proyecto compuesto permite que una base de datos grande se divida en fragmentos más manejables, permite que diferentes personas o equipos tengan la responsabilidad de diferentes partes del esquema general y permite la reutilización de definiciones de objetos de bases de datos en múltiples bases de datos.

La idea sería tener un proyecto base, que contenga las definiciones de objetos comunes y los proyectos específicos de la versión para los procedimientos que utilizan nuevas características. El proyecto de 2012 haría referencia al proyecto base y una compilación / construcción combinaría objetos de ambos.

El PITA sería que no puede anular un objeto en el proyecto base con un objeto en un compuesto, por lo que tendría que mantener los proyectos base, 2008 y 2012. Cuando deseaba una versión 2012 de un procedimiento en particular, tendría que eliminarla de la base y crear una versión en los proyectos 2008 y 2012.

He tenido una discusión abierta en MSDN sobre esta necesidad. No han progresado mucho. La situación ideal le permitiría marcar objetos db como "heredables" en proyectos base ssdt para que otros proyectos que hagan referencia al proyecto base o DAC no se quejen del objeto duplicado, y solo crearían el objeto base o "stub" si No existía. Esto le permitiría tener "capas" de modelos de bases de datos. Vea mi publicación en msdn Ampliación de soluciones compuestas SSDT con procedimientos almacenados anulados

Logré algo cercano a lo que se pide mediante el uso de eventos previos a la construcción. En mi caso, quería que se incluyeran diferentes usuarios e inicios de sesión en una implementación de acuerdo con la configuración que se estaba creando.

Para hacer esto, creé un archivo .sql para cada configuración de compilación, para cada usuario. Los marqué como Build Action 'None': (los puse en una subcarpeta del proyecto)

• Debug_SomeUser.sql
• Release_SomeUser.sql

Luego creé un archivo vacío SomeUser.sql (con Build Action = 'Build').

En la línea de comando del evento previo a la compilación:

Copy $(ProjectDir)subfolder\$(Configuration)_Someuser.sql $(ProjectDir)Someuser.sql

Era una molestia que un equipo de codificadores creara conflictos constantemente en git, por lo que también agregué a la línea de comando previa a la compilación

git update-index --assume-unchanged $(ProjectDir)Someuser.sql 

Fue bastante complicado hacer que esto funcionara, ya que tenía que considerar un número mucho mayor de usuarios y configuraciones, pero funciona.