1. El documento describe las problemáticas del desarrollo de bases de datos sin control de código y propone soluciones manuales y automáticas. 2. Presenta las herramientas SQL Server Data Tools y Data-Tier Application que permiten un ciclo de vida de desarrollo con control de código. 3. Concluye comparando las ventajas e inconvenientes de las soluciones manuales frente a las herramientas que automatizan el proceso.

1. Desarrollo con control de código contra
SQL Server (300)
Luís J. Morán Cuenca
REL300013
DPA - Relacional
lmoran@solidq.com
Enrique Catalá Bañuls
Mentor – Relational engine
MAP 2012 – Microsoft Technical Ranger – Microsoft Certified Trainer
ecatala@solidq.com

2. Problemática actual
Soluciones
 Manuales
 Automáticas
Desarrollo con ciclo de vida
Data-Tier Application component
SQL Server Data Tools
Conclusiones
Agenda

3.  Las bases de datos no tienen tratamiento adecuado
 Se siguen tratando como entidades independientes aisladas
 Las dependencias se gestionan manualmente
 Los errores en código T-SQL se encuentran solo cuando se
ejecuta dicho código
 Múltiples aplicaciones hacen uso de la misma BBDD
 Múltiples BBDD hacen uso entre ellas
 Aplicaciones hacen uso de múltiples versiones de SQL
Server
Problemática actual
Ciclo de vida

4. 1. La de los amantes del riesgo máximo
2. La de los que piensan que todo tiempo
pasado fue mejor
3. SQL Server Data Tier Applications
4. Proyectos de base de datos
5. SQL Server Data Tools
Problemática actual
Soluciones

5.  Sin desarrollo con control de código contra SQL
Server
 Sin control cambios en un SQL Server centralizado
 El que desarrolla el cambio es responsable de dicho
cambio
 El que desarrolla el cambio se encarga de subir el
cambio a pro
 ¿Entornos de desarrollo compartidos??¿Eso que
eh lo que eh? 
Soluciones
Amantes del riesgo máximo

6.  Solo un punto de fallo
 ¿Qué pasa si un developer sube un cambio y olvida comentar el
drop column?
 ¿Cómo gestionamos las actualizaciones?
 Grandes ideas acaban poniéndose en práctica 
 Usemos consultas ad-hoc!!!!
 Usemos ORM!!! ¿por qué hacer t-sql si ahora se lleva Entity
Framework?
 A la larga aparecen:
 Problemas de rendimiento
 Sobrecostes mantenimiento
 Paradas de servicio
Amantes del riesgo máximo
Las consecuencias
Y si ya unimos todo esto a una mala
política de backups… 

7.  Desarrollo con control de código contra SQL
Server…a base de scripts
 Se usa repositorio Source Safe…o incluso TFS pero “a modo de
backup de scripts”
 Gestion cambios de SQL Server centralizados
 El que desarrolla el cambio es responsable de dicho
cambio
 El cambio se sube a un repositorio con control de código
y hay un responsable de testing
 Entornos de desarrollo compartidos
 Hay un responsable de testing que testea los cambios antes de subir
a producción
Soluciones
Todo tiempo pasado fue mejor

8.  Los errores son pasados por alto ya que no saltan hasta
haberse ejecutado
 Son frecuentes retrasos de puesta a producción puesto
que el desarrollo fuerza codificar con seguridad
 IF EXISTS()/ALTER,…
 Los entornos de desarrollo compartidos tienen capacidad
limitada en ocasiones y se cae en tentación de no usarlos
 Se prueba localmente y no se tienen los cambios de otros
compañeros
 ¿Sincronización de esquemas?
 Mis compis reciben mi script y lo lanzan en sus entornos de prueba
(si, esos que no deberían tener local )
 ¿Despliegue? Ah, si…te refieres a lo de abrir el .sql y darle a
F5…pero si falla, juanito es el que se encarga 
Problemas de soluciones manuales

9. Problemática actual
Soluciones
 Manuales
 Automáticas
Desarrollo con ciclo de vida
Data-Tier Application component
SQL Server Data Tools
Conclusiones
Agenda

10.  No quiero mas responsabilidades, el despliegue que se
haga solo
 No quiero codificar más de lo imprescindible
 El código de verificación que se haga solo (if exists,…)
 No quiero perder el tiempo copiando ficheritos
 Centralización de todos cambios en un único fichero/instalador
 No quiero aprender otra herramienta!
 Entorno integrado con el que desarrollo mis aplicaciones
 Roles diferenciados
 DBA-DBD que se encargue de la BBDD
 Developer que se encarge de la aplicación cliente
 Pero centralizados
 Las mismas tools para ambos, pero distinta finalidad
Desarrollo con ciclo de vida
¿por qué?

11. ¿Es posible un ciclo de vida para DB Apps?
 Desarrollo
 Despliegue
 Administración y mantenimiento
Sigue siendo habitual comunicación 0 entre
developers y DBAs
 RESPUESTA: SI!!! Y además desde hace tiempo 
Desarrollo con ciclo de vida
Ciclo de vida

12.  Database Project
 Proyectos de Visual Studio pensados para desarrollar la capa de datos
 Visual Studio Professional como mínimo requerido
 Server Project
 Proyectos de Visual Studio pensados para desarrollar modelados de
objetos a nivel de servidor y de la base de datos master
 Visual Studio Professional como mínimo requerido
 Data-tier Application
 Proyectos para implementar la capa de datos incluyendo partes de nivel
de servidor.
 Compatible con SSMS y con VS.
 Data Tools
 Evolución de Database Project.
 Incluye lo mejor de Data-tier Applications y de database proyect
 Compatible con Visual Studio, pero no requiere edición especial
 Compatible también con SSMS
Desarrollo con ciclo de vida
Alternativas

13.  En el ciclo de vida, el Data-Tier application component nos
ayuda a la hora desde el punto de vista de desarrollo
Data Tier Application Component
Desarrollo
• No se puede capturar
información del
desarrollo
• Diseño de DB diferente
entre Dev y DBA
• Dificultad para
empaquetar la
aplicación DB
Desarrollo
• La información del
esquema de BBDD se
captura
automáticamente, asi
como sus cambios
• Se utiliza el diseño de
base de datos, que se
distribuye
• Empaquetado de
aplicación en un único
fichero .dacpac
Solucionado por…

14.  En el ciclo de vida, el Data-Tier application component nos
ayuda a la hora desde el punto de vista de despliegue
Data Tier Application Component
Despliegue
• Difícil centralizar y
controlar el despliegue
• Políticas de despliegue
para diferentes
versiones
• Comprobar y
mantener restricciones
de despliegue
• DBA no conoce la App
DB
Despliegue
•Despliegue mediante
un único fichero
autoejecutable .dacpac
•Control de despliegue
automático
independiente de
instancia
•Control de cambios en
tiempo de despliegue
automático
•DBA no necesita
conocer cambios y DEV
no necesita conocer
BBDD
Solucionado por…

15. Data Tier Application Component
Diagrama de despliegue

16.  Modelo casi completo de una aplicación de base de datos
 Esquemas, tablas, procedimientos almacenados
 Información referenciada
 Políticas de despliegue
 Empaquetado en un solo archivo .dacpac
 Mejora la comunicación entre Desarrollador y DBA
 Contiene la forma deseada al desplegar la aplicación
 Control de versiones (TFS)
 Integrado en VS 2010 y SQL08 R2
Data Tier Application Component
DAC
Data-Tier Application Component (DAC)
Esquema
Perfil de despliegue
Requisitos, Políticas de despliegue
Lógico
Tablas, Vistas, Claves,
Procedimientos
Físico
Usuarios, Logins,
Índices

17.  No se retiene información sobre ficheros
 Se puede registrar y extraer info de BBDD que use filegroups
 Al registrar la BBDD se crea
 Con 1 único fichero y filegroup (mejorado )
 Con tamaño inicial 3Mb y crecimiento de 1Mb 
 Si se genera un DACPAC desde SQL 2012, no se puede
importar hacia versión inferior
 Nombre de BBDD máximo 87 caracteres
 Tamaño .dacpac <=50Mb
Data Tier Application Component
Restricciones

18.  Los siguientes objetos no se soportan
 Objetos CLR y tipos de datos CLR
 Incluyendo geometry, geography y Hierarchyid
 Partitionado (ni esquemas ni funciones)
 Filestream
 Linked servers
 Objetos con accesos cross-database
 XML schema, XML indexes
 Cifrado (claves simétricas/asimetricas ó certificados)
 Ni tampoco objetos cifrados
 User defined aggregates
 Service broker
 Triggers DDL
 Roles de aplicación
 FTS catalogs
 Extended stored procedures
 Propiedades extendidas
 Sinónimos
 Objetos marcados deprecados
Data Tier Application Component
Restricciones

19. Data Tier Application Component
Restricciones
Operación SQL2012 SQL 08 R2 SQL
Azure
SQL 08 SQL 05 SQL
2000
Borrar SI SI SI >=SP2 No No
Desplegar SI SI SI >=SP2 No No
Extraer SI SI SI SI SI SI
Registrar SI SI SI >=SP2 No No
Actualizar SI SI SI >=SP2 No No
Operaciones
Cliente
SI SI SI No No No

20. Problemática actual
Soluciones
 Manuales
 Automáticas
Desarrollo con ciclo de vida
Data-Tier Application component
SQL Server Data Tools
Conclusiones
Agenda

21. SQL Server Data Tools

22.  ¿Qué es?
SQL Server Data Tools
Integra Proyectos BIDS
Entorno de Desarrollo Completo
Configuración Todas
Propiedades BBDD
Nuevas Capacidades y
Mejoras

23. SQL Server Data Tools
 Novedades
Editor T-SQL
“Enriquecido”

24. SQL Server Data Tools
 Inicialización de Proyectos
Importar desde Script

25. SQL Server Data Tools

26. DEMODEMO
SQL Server Data Tools

27.  ¿Qué tipo de futuro esperas para tu app?
Conclusiones
Comparativa final
Riesgo
Esfuerzo

28. Problemática actual
Soluciones
 Manuales
 Automáticas
Desarrollo con ciclo de vida
Data-Tier Application component
SQL Server Data Tools
Conclusiones
Agenda

29. Si quieres disfrutar de las mejores sesiones de
nuestros mentores de España y Latino América,
ésta es tu oportunidad.
http://summit.solidq.com/madrid/
Síguenos: