Visual Studio for Database Professional (DBPro)

¿Cómo puedo obtener Visual Studio for Database Professional (DBPro)?

Visual Studio for Database Professional (DBPro) nació como parte de la familia de productos Visual Studio 2005. Sin embargo, en particular esta edición de Visual Studio salió a mercado después del lanzamiento del resto de ediciones de Visual Studio 2005, motivo por el cual, para poder utilizar las características de Visual Studio for Database Professional (DBPro), tenemos dos principales caminos de disponibilidad:

• Adquirir o descargar Visual Studio 2005 Team Edition for Database Professional.
• Adquirir o descargar Visual Studio 2005 Team Suit. Esta es la única versión de Visual Studio 2005 superior a la Database Professional (DBPro), sin embargo, debido a que Database Professional (DBPro) salió a mercado después, Visual Studio 2005 Team Suit no incluye (de serie) las funcionalidades de Database Professional (DBPro). Eso sí, Microsoft ha dejado disponible para descargar un Add-in (conocido como DBPro) para Visual Studio 2005 Team Suit, el cual incluye las funcionalidades de Database Professional (DBPro) sin privarse de utilizar Visual Studio 2005 Team Suit. Es importante tener en cuenta que el Add-in DBPro funciona sólo y exclusivamente con Visual Studio 2005 Team Suit, es decir, el Add-in DBPro no funcion ni con Visual Studio 2005 Professional, ni con ninguna otra edición de Visual Studio 2005 que no sea Visual Studio 2005 Team Suit.

En el caso de desear obtener la correspondiente edición de la familia de productos de Visual Studio 2008, las opciones posibles de disponibilidad son:

• Adquirir o descargar Visual Studio 2008 Database Edition.
• Adquirir o descargar Visual Studio 2008 Team Suit.

Para mayor detalle, puede consultarse la tabla de comparación de versiones de Visual Studio 2008 ofrecida por Microsoft Visual Studio Team System 2008 Team Edition Comparison

En cualquier caso, soy partidario de adquirir Visual Studio mediante subscripción a MSDN, en vez adquirir Visual Studio como un producto independiente. Evidentemente, en cada caso es interesante evaluar los costes de las diferentes alternativas de Licencias posibles.

¿Para qué sirve Visual Studio for Database Professional (DBPro)?

Quizás la principal duda al plantearse utilizar Visual Studio for Database Professional (DBPro) sea saber para qué sirve. En términos generales, es fácil oir que Visual Studio for Database Professional (DBPro) es una herramienta para incorporar a las bases de datos SQL Server dentro del Ciclo de Vida de Software de nuestra organización: definición de entornos de Desarrollo, Pruebas Integradas, Pre-Producción, Calidad, Producción, etc. Vale... esto está muy bien... pero realmente ¿Qué es lo que hace DBPRo? ¿Para qué sirve DBPro? Es decir, dadas todas las herramientas disponibles por Microsoft para trabajar con Base de Datos (y más en particular con SQL Server), como SQL Server Management Studio (SSMS), Business Intelligence Development Studio (BIDS) especialmente por los proyectos de Integration Services (SSIS), Visual Studio con sus diferentes tipos de proyectos de Base de Datos y su famoso Explorador de Servidores, etc. ¿Qué más nos puede ofrecer Microsoft con Visual Studio for Database Professional (DBPro)?

• Trabajar esquemas de base de datos, sin conexión, como con cualquier otro proyecto más de Visual Studio.
• Soporte para refactorizar, es decir, al cambiar el nombre del campo de una tabla, aplicar dicho cambio en el resto de objetos dependientes, como por ejemplo en procedimientos almacenados que utilicen dicho campo (como si estuviésemos renombrando un método de una clase !!).
• Someter el esquema de una base de datos bajo un sistema Control de Código Fuente, como es el caso de Visual Souce Safe 2005 (VSS2005).
• Comparación de esquemas de bases de datos SQL Server (ej: comparar el esquema de una base de datos en desarrollo, con el correspodiente de Producción), de tal modo que podamos visualizar rápidamente las diferencias existentes entre dichos esquemas de base de datos.
• Comparación de datos de bases de datos SQL Server. Muy útil para poder saber si el contenido de una tabla en Producción es el mismo que en Pre-Producción, aunque personalmente para este tipo de comprobaciones, me encuentro más a gusto trabajando con Servidores Vinculados y/o con Consultas AdHoc (OPENROWSET u OPENQUERY). Al respecto, para quién le interese este tema, le aconsejo la lectura del artículo ¿Qué es un Servidor Vinculado? ¿Para qué sirve un Servidor Vinculado? ¿Cómo crear un Servidor Vinculado? ¿Cómo configurar un Servidor Vinculado?
• Generación de datos de prueba. Habitualmente, no pueden utilizarse los mismo datos en entornos de desarrollo y producción, ya sea por el volumen de información (ej: costes de almacenamiento, backups, etc.), como por la propia naturaleza de los datos (datos de caracter personal: médicos, económicos, etc.). Una solución para poder generar los datos de nuestros entornos de desarrolo, es utilizar Visual Studio for Database Professional (DBPro) como herramienta de generación de datos.
• Generación de Pruebas Unitarias de Base de Datos.
• Implementación de cambios de bases de datos. Esta característica me ha parecido excepcional (de hecho, además de probarla la he estado utilizando bastante tiempo, y en general admito estar muy contento), y está íntimamente relacionada con la Comparación de esquemas de bases de datos que antes comentamos. Es decir, podemos tener una base de datos de referencia (con el esquema deseado), he implementarlo por doquier, es decir, en cualquier base de datos que nos interese. El resultado dependerá del esquema actual de la base de datos sobre la que deseamos implementar, ya que analizará el esquema de origen y destino, y generará un Script de cambios personalizado. Por ejemplo, si cambiamos un campo VARCHAR(50) a VARCHAR(60) y dicho campo está indexado, Visual Studio for Database Professional (DBPro) se preocupará de eliminar el correspondiente índice, aumentar la precisión del campo, y volver a crear dicho índice. Además, los Scripts de cambios generados incluyen Control de Errores, facilitándonos la depuración en caso de error. Además de implementar los cambios de esquema de base de datos como resultado de una comparación de esquemas, si tenemos un proyecto de DBPro con un esquema de base de datos SQL Server, también podremos implementarlo (evidentemente) desde el propio Proyecto.
• Integración con Team Foundation Server (TFS), opcional (ej: publicar pruebas unitarias como parte de compilaciones). Esto no le he probado (i am sorry ;-), pero teniendo en cuenta todo lo que he oído sobre Team Foundation Server (TFS), como poder aplicar directivas a las operaciones de Checkin, servicios de compilación nocturna, integración con Project Server para gestión y seguimiento de proyectos de software, etc., la verdad es que me genera muy buenas expectativas (recordar que Team Foundation Server utiliza SQL Server como repositorio, al contrario que Visual Source Safe que utiliza el propio sistema de archivos).

Todo lo anterior (excepto el apartado relacionado con Team Foundation Server), lo he probado con Bases de Datos SQL Server 2005. Con SQL Server 2000, la documentación del producto confirma que también funciona. He aprovechado también para hacer alguna prueba de Visual Studio for Database Professional (DBPro) sobre bases de datos SQL Server 2000 y el resultado ha sido satisfactorio, aunque no realizado un conjunto de pruebas tan estricto como el realizado sobre SQL Server 2005. También he realizado pruebas con Visual Studio 2008 Database Edition sobre SQL Server 2005 con el mismo resultado satisfactorio. No he podido realizar pruebas con SQL Server 2008, debido este Artículo fué elaborado inmediatamente después de la salida de DBPro (Visual Studio 2005), y en aquel momento no estaba disponible SQL Server 2008 (tan sólo había ediciones Community Technology Preview - CTP).

Llegados a este punto, es importante destacar claramente las ventajas de Visual Studio for Database Professional (DBPro). Es decir, podemos trabajar con esquemas de base de datos SQL Server con los proyectos de base de datos existentes desde Visual Studio 2003 o incluso con Soluciones de SQL Server Management Studio, ambas alternativas susceptibles también de someterse bajo sistemas de Control de Código Fuente como Visual Source Safe. Sin embargo, como veremos más adelante, no tendremos disponible la Vista de Esquema, ni podremos importar ficheros SQL o esquemas de otras bases de datos, ni podremos refactorizar, ni tenemos Planes de Generación de Datos, ni podremos generar Scripts SQL con las sentencias DDLs de cambios de Base de Datos, etc. Es en este tipo de detalles dónde Visual Studio for Database Professional (DBPro) consigue diferenciarse y destacar, ofreciendo algo nuevo frente a las anteriores alternativas ofrecidas por Microsoft.

Así dicho, puede parecer que no es para tanto, pero os pongo un ejemplo de caso de uso. Con Visual Studio 2003 o Visual Studio 2005 o SQL Server Management Studio (SSMS), podemos crear una solución o proyecto con nuestras sentencias DDL de creación de nuestra base de datos SQL Server. Vale... pues ahora imaginar que tenemos dicha solución o proyecto y además una base de datos en la que la hemos implementado, y que ya está en producción (es decir, tiene datos). Si queremos agregar una nueva columna a una tabla ¿que hacemos? pues tendremos que alterar la sentencia DDL del correspondiente CREATE TABLE, pero claro, ¿cómo lo implementamos? pues de forma adicional, tendremos que crearnos una sentencia DDL con el correspondiente ALTER TABLE... pero claro, esto añadirá la columna al final de la tabla, y quizás nosotros queramos mantener la nueva columna en una posición determinada, en cuyo caso no es suficiente con un ALTER TABLE, sino que es necesario hacer un CREATE TABLE con otro nombre, cargar la nueva tabla con un INSERT INTO, y seguidamente eliminar la tabla original y renombrar la nueva. A todo esto, habrá que añadir control de errores y transaccionalidad, no sea que nos casque a la mitad, y se nos monte un pollo que se cague la perra... ¿lo véis? pues este es el caso más simple, es decir, la tabla puede tener Triggers, Foreign Keys, índices, Vistas, etc... ¿Visualizáis? Pues ahora proyectar este problema en el tiempo, es decir, a lo largo de la vida de un proyecto de software las bases de datos sufren multitud de modificaciones, de tal modo que podemos tener diferentes implementaciones en distintos clientes, cada una con una versión distinta del esquema de nuestra base de datos... en este caso, ir alterando las sentencias CREATE es fácil, pero gestionar las sentencias ALTER en función de la versión de esquema de base de datos origen, y la versión de esquema de base de datos destino (que no tiene siempre porqué ser la última versión), es un punto infierno !! y aquí, es dónde llegan los señores de Microsoft, y te permiten que sólo te preocupes de diseñar tu esquema de tu base de datos SQL Server, y darle al botoncito ese de Implementar (Deploy)... y ya está ! Buenísimo, eh !! ahora vas, y lo difundes ;-) Pero el caso, es que esto es sólo un caso práctico (que no el único) de las ventajas ofrecidas por Visual Studio for Database Professional (DBPro).

En resumidas cuentas, Visual Studio for Database Professional (DBPro) es una herramienta que integra a las bases de datos (SQL Server) en el Ciclo de Vida del Software, gracias a un conjunto (varias) de funcionalidades extraordinarias que no estaban incluidas hasta el momento en la familia de productos de Visual Studio (ni tampoco con SQL Server), y que al final se limita a simplemente un conjunto de plantillas de proyecto de Visual Studio (bajo la rama Database Projects), nuevas opciones de menú (el nuevo menú Data de Visual Studio 2005), y nuevas opciones de configuración (nodo Database Tools del diálogo Options), como se representa en la siguiente imagen (bueno... fotomontaje ;-).

Antes de continuar, es importante tener en cuenta lo siguiente:

• Algunas de las funcionalidades anteriores, requieren la creación de un Proyecto Visual Studio 2005 de DBPro, mientras que otras funcionalidades pueden utilizarse sin necesidad de crear ningún Proyecto de Visual Studio 2005 (es decir, directamente desde el menú Data de Visual Studio).
• Utilizar un Proyecto Visual Studio 2005 de DBPro, tiene como requisito tener una Instancia de SQL Server local (aunque sea SQL Express), es decir, en el equipo del desarrollador o del administrador (DBA) de base de datos. Esta Instancia de SQL Server será utilizada por el Proyecto para realizar las validaciones en Tiempo de Diseño. Para especificar la Instancia de SQL Server que deseamos utilizar, desde el diálogo Opciones de Visual Studio nos posicionaremos en Database Tools -> Design-time Validation Database (esta configuración, sólo es necesario realizarla una única vez). A continuación se incluye un pantallazo (una imagen vale más que mil palabras ;-):

En lo relacionado con el requisito de tener una Instancia de SQL Server local, recordar que con Visual Studio for Database Professional (DBPro) se incluye licencia de una Instancia de SQL Server 2005 Developer. Además, también es posible descargar gratis ediciones de SQL Server como SQL Express, o SQL Express with Advanced Services (esta última incluye Búsqueda de Texto - Full Text Search - y Reporting Services).

Resumiendo ¿Qué podemos hacer con Visual Studio for Database Professional (DBPro)?

• Crear un Proyecto Visual Studio 2005 de DBPro. Podremos examinar el Proyecto a través de dos vistas: la vista del Explorador de Soluciones (Solution Explorer) muestra el proyecto de DBPro conforme a su estructura interna de ficheros y directorios, mientras que la vista de Esquema (Schema View) muestra el proyecto de DBPro como un conjunto de objetos de base de datos organizados jerárquicamente según su tipo (es la Vista de Esquema la que utilizaremos para Refactorizar, crear Pruebas Unitarias, etc. como veremos un poco más adelante). En cualquier caso, nuestro proyecto DBPro nos permitirá trabajar con el esquema de nuestra base de datos en desconexión (es decir, no podremos alterar directamente la base de datos). Es muy importante tener en cuenta que un Proyecto DBPro almacena el esquema de base de datos que estamos desarrollando, como un conjunto de ficheros SQL con sus sentencias DDL, por lo tanto a este respecto, no nos agamos ilusiones con unas fantásticas herramientas gráficas para diseñar el esquema de la base de datos SQL Server. Continuando con nuestro, las funcionalidades que ofrece un Proyecto de DBPro son en particular:
  
  
  • Desarrollar el esquema de nuestra base de datos SQL Server, incluyendo la creación, modificación y eliminación de tablas, vistas, procecimientos almacenados, funciones, objetos de Service Broker (Colas, Contratos, Tipos de Mensaje, etc.), funciones de particionamiento, usuarios de base de datos, roles, etc. Recordar que lo que vamos a desarrollar aquí son sentencias DDL (ej: CREATE TABLE, CREATE PROCEDURE, etc). Otro detalle, es que en un Proyecto DBPro se utiliza un fichero para cada objeto, teniendo en cuenta que un índice o una restricción serán considerados objetos diferentes (y en consecuencia, se almacenarán en ficheros diferentes), motivo por el cual trabaremos con muchos ficheros con sentencias DDL. De hecho, al eliminar un objeto de base de datos, se eliminarán también los objetos reconocidos como objetos hijos, mostrándose un diálogo de advertencia pidiendo confirmación para continuar (Deleting this object will also delete any child objects its contain. Are you sure you want to delete this object?). Por ejemplo, al eliminar un objeto tabla del Proyecto DBPro, se eliminarán en cascada los objetos índice, constraints, etc.
    
    
  • Importar el esquema de una base de datos SQL Server existente (opción Import database), o de un fichero script (Import script) de secuencias de comando SQL (.sql). Esto resulta útil, ya que habitualmente no empezaremos nuestro proyecto desde cero, pudiendo importar primero, para seguidamente poder continuar desarrollando el esquema de nuestra base de datos. Debe tenerse en cuenta, que la importación desde una base de datos SQL Server existente sólo se puede hacer una vez (después de la primera vez, la opción Import database desaparece, como cual carroza que se convierte en calabaza ;-), sin embargo, podemos importar ficheros de secuencias de comando SQL (.sql) todas las veces que lo necesitemos. Aunque aquí hay truco, es decir, aunque sólo podemos importar el esquema de una base de datos una única vez, es posible hacer una comparación de esquemas entre un Proyecto DBPro y una Base de Datos, para incorporar al Proyecto DBPro las diferencias existentes, todas las veces que nos sea necesario (ojo, comparar con Source la Base de Datos SQL Server, y Target el Proyecto DBPro, y si todo OK, click en el botón Write Updates - un botón maravilloso ;-). La ventaja de estas comparaciones de esquema radica en que es más fácil encontrarse a gusto modificando y desarrollando sobre una base de datos de verdad (con tu SQL Server Management Studio, etc.), que estar pegándose con Scripts SQL de DDLs. Por supuesto, una vez que hemos importado objetos de esquema a nuestro Proyecto de DBPro, podremos alterarlos o eliminarlos, someterlos bajo el control de código fuente, refactorizar, etc. Muy cómodo, porque nos permite evitar picarnos a mano las sentencias DDL.
    
    
  • Refactorizar, es decir, cambiar el nombre de un objeto (ej: de una tabla, de un campo de una tabla, de un procedimiento almacenado, etc.) con la particularidad de automáticamente realizar también el cambio en aquellos sitios en que esté referenciado (ej: cambiar el nombre de una tabla, y alterar automáticamente todos los procedimientos almacenados, vistas, etc. para que la utilicen, para que empleen el nuevo nombre), incluyo en pruebas unitarias, archivos de generación de datos, etc., ahorrando la realización de este trabajo de forma manual (recordar que al Refactorizar no se tiene en cuenta el código SQL Dinámico). Esto ya se podía hacer en Visual Studio con las Clases, es decir, podíamos refactorizar los nombres de métodos, etc., de tal modo, que los señores de Microsoft han aplicado dicha idea al desarrollo de Bases de Datos SQL Server. Ahora bien ¿Cómo refactorizar objetos de esquema de base de datos SQL Server en un Proyecto Visual Studio 2005 de DBPro?. Pues tan fácil como seleccionar la Vista de Esquema (Schema View), hacer click con el botón derecho sobre el objeto que se desea refactorizar (renombrar), y click en Refactor -> Rename. En este momento, se mostrará un diálogo en el que especificar el nuevo nombre, y alguna otra opción como si deseamos previsualizar los cambios (Preview changes). En algunos casos como al refactorizar el nombre de una tabla, Visual Studio for Database Professional (DBPro) avisa del riesgo existente de pérdida de datos al implementar dicho esquema (tan cierto es la existencia de dicho riesgo, como cierto es que DBPro nos avisa). En consecuencia, y como se comenta más adelante en este artículo, es muy recomendable revisar los Scrits SQL de implementación (no es acosejable ejecutar los Scripts SQL de implementación a ciegas... un poco de respeto, que son sentencias DDL !! ;-). A continuación se muestra una pantalla capturada del diálogo de refactorización:
    
    
    
    
    
  • Planes de Generación de datos de prueba, de gran utilidad para la creación de los datos en entornos de desarrollo, pruebas unitarias, pruebas integradas, entornos de pre-producción, entornos de laboratorio, etc. Este es un tema muy gracioso, ya que en la realidad, cuando estás por ahí con clientes, te encuentras cosas como que los desarrolladores tengan acceso a los datos reales en entornos de Data Warehouse o incluso en entornos operacionales, y en esto me refiero a casos como conocidas empresas de seguro españolas (y hablo por experiencia... jeje ;-). Centrándonos, en nuestro Proyecto DBPro podremos crear ninguno, uno, o varios Planes de Generación de Datos, para con ellos alimentar (generar los datos necesarios) las tablas que deseemos. Los Planes de Generación de Datos se basan en los Generadores, que son nuestras fábricas de valores. Un Generador permite generar datos de un tipo determinado en función de como lo parametricemos (ej: porcentaje de filas NULL, precisiones máxima y mínima de los datos generados, unicidad de los datos generados - vamos, que si se pueden repetir o si son únicos -, etc.). Una gran ventaja de los Planes de Generación de Datos es que aunque los datos generados son aleatorio, estos también son repetibles, es decir, si ejecutamos un Plan de Generación de Datos varias veces, el conjunto de datos resultante en todos los casos será el mismo (y así ha sido en mis pruebas). Suelen basarse en una semilla (seed) de inicialización, por lo tanto, mientras mantengamos el valor de la propiedad Seed, el resultado generado será el mismo (repetible). El hecho de que los datos generados sean repetibles es una característica fundamental, ya que esto nos permitirá probar nuestro software n veces sobre exactamente el mismo conjunto de datos, muy útil en ciertos momentos de depuración de código fuente y resolución de incidencias. Disponemos de Generadores para diferentes tipos de datos de SQL Server (los Generadores Tinyint, Smallint, Integer, Bigint, Real, Float, String), y adicionalmente, disponemos del Generador Regular Expression (de ayuda para generar teléfono, códigos postales, etc) y del Generador Data Bound Generator (permite generar datos en función de los valores existentes en otra tabla - ej: guardamos en una tabla Apellidos de personas, y así conseguimos rellenar tablas con Apellidos de verdad, no con caracteres ASCII generados de forma totalmente arbitraria y sin ningún sentido). He probado todos estos Generadores, y el resultado ha sido muy satisfactorio. También es posible crear nuestros propios Generadores (es decir, Generadores personalizados) desarrollándolos con Visual Studio, pero esto ya no lo he probado (al menos, comentarlo, por si alguién tiene la necesidad, que pueda investigarlo). También es importante comentar que DBPro tendrá en consideración las columnas sobre las que se aplican restricciones de Clave Externa, para conseguir generar datos sobre esquemas en que se aplica Integridad Referencial. Me ha parecido muy interesante poder especificar el número de filas que deseamos generar para cada tabla, de tal modo que podamos crear entornos de desarrollos proporcionales a los entornos de producción, o bien, generar entornos de pre-producción donde realizar pruebas de carga y pruebas de rendimiento sobre grandes volúmenes de datos. También me ha parecido muy útil, poder previsualizar los datos generados, de forma que podamos revisar y depurar nuestros Planes de Generación de Datos.

    Para finalizar con este apartado queda responder a una pregunta ¿Cómo crear un Plan de Generación de Datos en un Proyecto DBPro? Pues fácil, desde el Explorador de Soluciones (Solution Explorer) click con el botón derecho sobre nuestro proyecto, y seguidamente click soble Add -> Data Generation Plan del menú contextual. Con esto, crearemos un nuevo Plan de Generación de Datos (un fichero con extensión.dgen),que por defecto insertará 50 filas en cada tabla del Proyecto DBPro. A partir de aquí, deberemos modificar nuestro Plan de Generación de Datos, para que sólo actúe sobre las tablas y campos que deseamos, especificar cuantas filas queremos generar en cada tabla, y configurar el Generador utilizado para cada campo de cada tabla (es decir, qué Generador deseamos utilizar, y las propiedades de dicho Generador), etc.
    
    

  • Creación y ejecución de Pruebas Unitarias de procedimientos almacenados, funciones de usuario, etc. La creación de pruebas unitarias implica la creación o utilización de un proyecto existente Visual Studio 2005 del tipo Proyecto de Pruebas (Test Project), ya sea en Visual Basic o C Sharp. Las pruebas unitarias son código T-SQL asignado a archivos de clase (código de la prueba, y opcionalmente código pre y post para preparar y limpiar la base de datos), pudiendo contener una clase a una o varias pruebas unitarias. A cada prueba pueden asignárseles ninguna, una o varias Condiciones de Prueba (la ausencia de condiciones de prueba hace que se apruebe automáticamente). Existen diferentes Condiciones de Prueba, cada una con diferentes propiedades. Las concidiones de prueba que estén definidas pueden habilitarse o deshabilitarse. Los tipos de condiciones de prueba existentes son: Valor escalar, Tiempo de ejecución, ResultSet vacío, Recuento de filas, No se admite ResultSet vacío, No concluyente.
    
    En la configuración del Proyecto de Prueba, puede definirse la conexión sobre la que ejecutar la prueba, indicar si desplegar previamente un esquema (de un proyecto DBPro), e indicar si ejecutar previamente un Plan de Generación de Datos (uno y sólo uno).
    
    ¿Cómo crear una Prueba Unitaria de base de datos SQL Server de un Proyecto DBPro? Pues fácil, simplemente seleccionar la Vista de Esquema (Schema View), hacer click con el botón derecho sobre el objeto del que se desea crear una Prueba Unitaria, y click en Create Unit Test. Se mostrará un diálogo en el que será necesario especificar el Proyecto de Pruebas (Test Project) que deseamos utilizar (o bien un Proyecto de Pruebas nuevo), el nombre de la Clase del Proyecto de Pruebas que deseamos utilizar, la conexión SQL que deseamos utilizar para ejecutar las Pruebas Unitarias (esto sólo es necesario especificarlo una vez para el Proyecto de Pruebas), el código Transact-SQL de la Prueba Unitaria, y las Condiciones de Prueba (Test Conditions). También es posible especificar código Transact-SQL para ejecutar antes y/o después de la Prueba Unitaria (para preparar o limpiar la base de datos SQL Server), etc.
    
    ¿Cómo ejecutar las Pruebas Unitarias de base de datos SQL Server de un Proyecto DBPro? Para ejecutar todas las pruebas pulsar F5; para ejecutar una prueba unitaria individualmente, en la ventana Vista de pruebas, click con el botón derecho sobre la Prueba Unitaria deseada, y después click sobre Ejecutar.
    
    
  • Someter el Proyecto bajo un sistema de Control de Código Fuente, como es el caso de Visual Source Safe o Team Foundation Server (TFS). El hecho de poder someter el esquema de una base de datos SQL Server bajo el Control de Código Fuente es una gran ventaja que en algún momento de necesidad nos puede ayudar a devolver nuestra base de datos a un estado anterior. Esto es posible debido a que en nuestro Proyecto, todo nuestro trabajo toma forma internamente en un conjunto de ficheros y directorios (elegante a la par que sencillo ;-) susceptibles (como no) de ser versionados bajo cualquier sistema de Control de Versiones o de Control de Código Fuente.
    
    
  • Implementar el esquema de nuestro proyecto DBPro sobre una Instancia de SQL Server, ya sea una instancia local del desarrollador, en una instancia compartida por un equipo de desarrolladores, etc., dando así pié a primeras Pruebas Unitarias y otros tipos de comprobaciones. Para ello, se debe especificar la conexión a la instancia SQL Server de destino y el nombre de la base de datos de destino en las propiedades del Proyecto DBPro, pestaña Generar (Build). De forma adicional, es importante revisar todas las propiedades del Proyecto DBPro, tanto de la Pestaña Generar (Build), como del resto de pestañas, ya que podremos encontrar varias opciones que nos pueden resultar de interés como Execute deployment script in single-user mode, perform 'smart' column name matching when you add or rename a column, Generate DROP statements for objects that are in the target database but that are not in the database project, especificar propiedades de la base de datos (intercalación, opciones ANSI de SQL Server, Modo de Recuperación o Modo de Registro, etc.). Finalmente, hacer click con el botón derecho sobre el Proyecto (en el Explorador de Soluciones - Solution Explorer) y click Implementar (Deploy).
  
  
  
• Comparar Esquemas de bases de datos SQL Server (no es necesario crear Proyecto en DBPro, excepto que se desee comparar un Proyecto DBPro con una Base de Datos o viceversa). Esta funcionalidad, no sólo permite comparar dos bases de datos SQL Server (o comparar un Proyecto DBPro con una base de datos SQL Server), sino que además permite generar un Script SQL para la implementación de los cambios (diferencias), con todas las sentencias SQL (principalmente sentencias DDL) necesarias. Para realizar una comparación de esquemas de base de datos, simplemente utilizaremos la opción New Schema Comparison del menú Data -> Schema Compare de Visual Studio, especificando cuál es el esquema de origen (sea un Proyecto DBPro o una base de datos SQL Server) y cuál es el esquema de destino (sea un Proyecto DBPro o una base de datos SQL Server). Como comentamos anteriormente, sólo es posible importar a un Proyecto DBPro un esquema de base de datos una única vez, pero por el contrario, una vez importado el esquema de una base de datos a un Proyecto DBPro, podremos realizar una comparación de esquemas entre la base de datos y el Proyecto DBPro, para de esta forma importar las diferencias (ojo con el sentido, ya que no es lo mismo tomar como Source el Proyecto DBPro y como Target el esquema real de una base de datos, que al contrario). En cualquier caso, también resulta muy útil para comparar el esquema de dos bases de datos.
  
  Quiero resaltar la importancia de revisar las opciones de configuración de las comparaciones de esquema (en el diálogo Opciones de Visual Studio, el nodo Database Tools - Schema Compare), ya que es en este diálogo dónde configuraremos detalles muy importantes de la comparación de esquemas (ej: forzar que el orden de las columnas sea idéntico, ignorar espacios, ignorar triggers, ignorar filegroups, ignorar estadísticas, ignorar los nombres de las restricciones e índices, etc.), con el fin de configurar el comportamiento deseado de la comparación de esquemas.
  
  En caso de desear implementar el Script SQL con la secuencia de comandos de cambios (las sentencias DDL), es muy importante revisar el Script SQL de cambios antes de ejecutarlo. Por ejemplo, si renombramos una columna y seguidamente realizamos una comparación de esquemas ¿Cómo puede Visual Studio 2005 decidir si se ha eliminado la columna y creado otra columna nueva con otro nombre, o si sólo se ha cambiado el nombre de la columna? Evidentemente, existen ciertas situaciones en las que las opciones de configuración de las comparaciones de esquema establecidas pueden generar el resultado desea o puede que no, así como existen casos en los que alguna modificación manual del Script SQL de cambios pueda ser necesaria o muy recomendable (ej: evitar un DROP y un CREATE, empleando un ALTER).
  
  El principal inconveniente (bajo mi opinión, y bajo el alcance de la experiencia que tengo con DBPro), es que siempre se realiza una comparación completa de los esquemas origen y destino. En el momento en que tenemos un volumen grande de objetos de base de datos, dicha comparación puede resultar muy costosa, cuando en ocasiones sólo deseamos evaluar las diferencias entre un conjunto de objetos muy reducidos (ej: tenemos 1800 procedimientos almacenados, pero sólo queremos evaluar las diferencias de 15 de ellos). También es cierto, que el rendimiento de la red y la carga de trabajo de las bases de datos comparadas, pueden influenciar de forma determinante en el tiempo de respuesta de la comparación de esquemas de DBPro.
  
  Del mismo modo, es muy importante comentar que una vez realizada la comparación de esquemas podemos omitir los objetos que queramos. Por ejemplo, si comparamos los esquemas de desarrollo y producción para implementar cambios, podemos estar en el caso de querer subir a producción 15 procedimientos almacenados, pero en realidad en desarrollo existen muchos más procedimientos almacenados diferentes, lo que ocurre es que se trata de procedimientos almacenados que están aún en pleno desarrollo y hasta que no se finalice su codificación no se desean subir a producción. En este caso, podemos omitir dichos procedimientos almacenados, para así sólo generar en el Script SQL de cambios, las sentencias DDL necesarias para los objetos que estrictamente deseamos subir a producción.
  
  Otro pequeños inconveniente es la existencia de objetos incorrectos en el Proyecto DBPro. Me explico. Imaginar un Procedimiento Almacenado con tres parámetros, los cuales se especifican separados por comas en la correspondiente sentencia CREATE PROCEDURE. Bien, pues ahora imaginar que se nos olvida separar por comas los parámetros en el Script SQL de nuestro Proyecto DBPro. ¿Lo Visualizáis? Pues vale, el tema está en que dicho objeto está incorrecto (evidentemente, sintácticamente ha perdido todo sentido), y en esta situación si realizamos una comparación de esquemas se tomará como si este objeto no existiese, lo cual es un detalle de vital importancia, ya que al implementar nuestro Proyecto DBPro sobre una base de datos existente en la que ya estaba creado dicho Procedimiento Almacenado, la implementación implicará la eliminación de dicho Procedimiento Almacenado (se ejecutará un DROP PROCEDURE, sin dolor). Es interesante tener en cuenta este tipo de comportamientos, pero también debemos ser conscientes de que cuando un objeto está incorrecto o inválido en nuestro Proyecto DBPro, se mostrará su correspondiente icono con una aspa roja (dicen que el que avisa no es traidor).
  
  
• Comparar Datos de bases de datos SQL Server (no es necesario crear Proyecto en DBPro). Esta funcionalidad permite seleccionar las tablas y vistas que se desean comparar (deben disponer de clave primaria o índice único), así como generar una secuencia Transact-SQL de cambio o bien aplicar dichos cambios directamente. En cualquier caso, se debe indicar qué base de datos se toma como origen, y cuál se toma como destino. En el diálogo Opciones de Visual Studio, pueden configurarse opciones que afectan al propio funcionamiento de la comparación de datos (ej: excluir columnas identitys, quitar espacios, etc). Esta funcionalidad también la he probado, aunque debo adminitir que no he realizado demasiadas pruebas (eso sí, en las pruebas realizadas se ha comportado correctamente).
  
  

Conclusiones sobre Visual Studio for Database Professional (DBPro)

Aquí finaliza este artículo introductorio sobre Visual Studio for Database Professional (DBPro), a través del cual, espero haber conseguido transmitir las funcionalidades que ofrece DBPro, así como facilitar la comprensión de la forma en que DBPro integra a las bases de datos SQL Server en el Ciclo de Vida del Software, bastante importante en entornos de desarrollo de software intensivo o crítico. Por supuesto, espero haber conseguido transmitir una ligera idea de qué se puede hacer con Visual Studio for Database Professional (DBPro) y cómo funciona Visual Studio for Database Professional (DBPro).

Durante la elaboración de las pruebas de este Artículo, admito (y es una opinión personal) que se hecha de menos no tener incluidas algunas de las funcionalidades de DBPro (como es el caso de la comparación de esquemas de base de datos) dentro de SQL Server Management Studio (SSMS), ya que sería un complemento ideal y natural de SSMS. En cualquier caso, de una u otra forma, ya tenemos disponible esta funcionalidad aunque sea bajo el techo de la familia de productos de Visual Studio.

Poco más, sólo transmitir mi satisfación relativa a las pruebas realizadas sobre Visual Studio for Database Professional (DBPro), pues existiendo algunos aspectos mejorables, se ha presentado como un producto software de gran potencia y utilidad.

Como siempre, espero que os sea de ayuda !!