He estado jugando con cómo estructurar una respuesta a esta pregunta desde que se publicó originalmente. Esto es difícil ya que el caso de VS2010 no se trata de describir las características y beneficios de la herramienta. Se trata de convencer al lector de hacer un cambio fundamental en su enfoque para el desarrollo de bases de datos. No es fácil.
Hay respuestas a esta pregunta de profesionales experimentados en bases de datos, con una mezcla de antecedentes que abarca DBA, desarrollador / dba y OLTP y almacenamiento de datos. No es viable para mí abordar esto para cada faceta del desarrollo de la base de datos de una sola vez, así que voy a tratar de presentar un caso para un escenario particular.
Si su proyecto cumple con estos criterios, creo que hay un caso convincente para VS2010:
- Su equipo está utilizando VS2010 para el desarrollo de aplicaciones.
- Su equipo está utilizando TFS para el control de origen y la gestión de compilación.
- Su base de datos es SQL Server.
- Su equipo ya tiene o está interesado en las pruebas automatizadas VS.
Si está evaluando VS2010 para el desarrollo de la base de datos, su biblia será la Guía de base de datos de Visual Studio de Visual Studio ALM Rangers . Cualquier cita que siga y que no tenga referencias será de este documento.
Nos vamos entonces ...
¿Por qué el proceso de desarrollo de la base de datos es diferente del desarrollo de aplicaciones?
Datos. Si no fuera por esos datos molestos, el desarrollo de la base de datos sería un obstáculo. Podríamos DROP todo en cada lanzamiento y olvidarnos de esta problemática gestión de cambios.
La existencia de datos complica el proceso de cambio de la base de datos porque los datos a menudo se migran, transforman o vuelven a cargar cuando se introducen cambios por esfuerzos de desarrollo de aplicaciones que afectan la forma de las tablas de la base de datos u otros esquemas de datos. A lo largo de este proceso de cambio, los datos de calidad de producción y el estado operativo deben protegerse contra los cambios que puedan poner en peligro su integridad, valor y utilidad para la organización.
¿Qué hay de malo con SSMS?
Se llama SQL Server Management Studio por una razón. Como herramienta independiente, no es práctico administrar sus esfuerzos de desarrollo si va a seguir las mejores prácticas aceptadas.
Solo con los scripts, para aplicar de manera significativa las prácticas establecidas de control de código fuente a su desarrollo, deberá mantener ambas definiciones de objetos (por ejemplo, un script CREATE TABLE) Y cambiar los scripts (por ejemplo, ALTER TABLE) Y trabajar duro para asegurarse de que permanezcan sincronizados.
La cadena de versiones para cambios en una tabla se vuelve bastante tonta bastante rápido. Un ejemplo muy simplista:
-- Version 1
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20))
-- Version 2
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(50))
-- Version 3
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(100))
Para la versión 3, el script de cambio de base de datos contiene:
ALTER TABLE dbo.Widget ADD Description VARCHAR(50)
ALTER TABLE dbo.Widget ALTER COLUMN Description VARCHAR(100)
Si la versión en vivo de esta base de datos es la versión 1 y nuestra próxima versión es la versión 3, la secuencia de comandos a continuación sería todo lo que se necesitara, pero en su lugar se ejecutarán las dos declaraciones ALTER.
ALTER TABLE dbo.Widget ADD Description VARCHAR(100)
5 años de sprints de 4 semanas se suman a algunos scripts de versiones entretenidos y requieren un manejo adicional de personal para minimizar el impacto en el tiempo de implementación.
Entonces, ¿hay algo malo con SSMS? No, es bueno para lo que sirve, administrar y administrar SQL Server. Lo que ni siquiera pretende hacer es ayudar a un desarrollador de bases de datos con la tarea (a veces) muy compleja de gestionar el cambio.
Si no puede construir todas las versiones de la base de datos desde el origen y actualizar a cualquier versión futura, su control de origen está roto. Si no lo crees, pregúntale a Eric Sink .
¿Qué pasa con SSMS + <- insertar herramienta de comparación de esquemas ->?
Este es definitivamente un paso en la dirección correcta y quita gran parte del esfuerzo manual requerido para mantener los scripts. Pero (y es un gran pero), típicamente hay pasos manuales involucrados.
Las populares herramientas de comparación de esquemas se pueden automatizar e integrar completamente en el proceso de compilación. Sin embargo, en mi experiencia, la práctica más común es que una comparación se ejecute manualmente, los scripts resultantes se resaltan, se registran en el control de origen y luego se ejecutan manualmente para implementar. No está bien.
Cada vez que los humanos falibles tenemos que involucrarnos en el proceso de construcción o despliegue, introducimos riesgos y hacemos que el proceso no sea repetible.
Si usted y su equipo se encuentran entre los pocos que tienen comparación e implementación de esquemas totalmente automatizados, ¡felicitaciones! Ustedes son los más propensos a estar abiertos a los beneficios que VS2010 tiene para ofrecer como:
- Ya has aceptado que los pasos manuales son peligrosos.
- Ves el valor de la automatización.
- Estás dispuesto a invertir el tiempo necesario para que funcione.
Si no puede crear una compilación en un solo paso, o implementar en un solo paso, su proceso de desarrollo e implementación se interrumpe. Si no lo crees, pregúntale a Joel Spolsky .
¿Por qué VS2010?
La pregunta que planteó @NickChammas es buscar características increíbles que demuestren por qué VS2010 cambia las reglas del juego para el desarrollo de bases de datos. No creo que pueda presentar el caso sobre esa base.
Quizás cómicamente, donde otros ven defectos en esta herramienta, veo fuertes razones para la adopción:
- Tendrás que cambiar tu enfoque.
- Usted y su equipo se verán obligados a trabajar de una manera diferente.
- Tendrá que evaluar el impacto de cada cambio, en detalle, en detalle.
- Serás guiado para hacer que cada cambio sea idempotente .
Si usted es el único DBA en un proyecto, administrando todos los cambios en la base de datos, este razonamiento debe sonar ridículo y absurdo. Sin embargo, si cree que @BrentOzar tiene un punto y una de las nuevas reglas es que Todos son el DBA , tendrá que controlar el cambio de la base de datos de una manera con la que todos los desarrolladores del equipo puedan trabajar.
La adopción de proyectos de bases de datos puede requerir un cambio mental (los viejos hábitos son difíciles de romper ) para algunos desarrolladores o al menos un cambio en el proceso o los flujos de trabajo. Los desarrolladores que hayan desarrollado aplicaciones de bases de datos
en las que la base de datos de producción representa la versión actual de la base de datos deberán adoptar un enfoque basado en el código fuente en el que el código fuente se convierta en el vehículo en el que se realizan cambios en las bases de datos . En los proyectos de base de datos de Visual Studio, el proyecto y el código fuente es la "Una versión de la verdad" para el esquema de la base de datos y se administra utilizando flujos de trabajo SCM que probablemente ya estén siendo utilizados por el desarrollador u organización para otras partes de su pila de aplicaciones. Para los datos, la base de datos de producción sigue siendo su "Una versión de la verdad" como debería ser.
Hemos llegado al cambio fundamental que es necesario para adoptar con éxito el enfoque VS2010 para el desarrollo de bases de datos ...
Trate su base de datos como código
No más cambios en la base de datos en vivo. Cada cambio de base de datos seguirá el mismo patrón que un cambio de aplicación. Modificar fuente, compilar, desplegar. Este no es un cambio temporal de dirección de Microsoft, este es el futuro para SQL Server . La base de datos como código está aquí para quedarse.
El desarrollador de la base de datos define la forma del objeto para la versión de la aplicación, no cómo mutar el objeto existente en el motor de la base de datos a la forma deseada. Puede preguntarse: ¿cómo se implementa esto en una base de datos que ya contiene la tabla de clientes? Aquí es donde entra en juego el motor de implementación. Como se mencionó anteriormente, el motor de implementación tomará la versión compilada de su esquema y la comparará con un objetivo de implementación de la base de datos. El motor de diferenciación producirá los scripts necesarios para actualizar el esquema de destino para que coincida con la versión que está implementando desde el proyecto.
Sí, hay otras herramientas que siguen un patrón similar y para proyectos fuera de las limitaciones que puse en mi respuesta, merecen la misma consideración. Pero, si está trabajando con Visual Studio y Team Foundation Server ALM, no creo que puedan competir.
¿Qué hay de malo con los proyectos de base de datos VS2010?
Editar: Entonces, ¿cuál es tu punto?
@AndrewBickerton mencionó en un comentario que no he respondido la pregunta original, así que intentaré resumir "¿Por qué debería usar Visual Studio 2010 sobre SSMS para el desarrollo de mi base de datos?" aquí.
- SSMS no es una herramienta de desarrollo de bases de datos. Sí, puede desarrollar TSQL con SSMS, pero no proporciona las características completas de IDE de VS2010.
- VS2010 proporciona un marco para tratar su base de datos como código.
- VS2010 trae análisis de código estático a su código de base de datos.
- VS2010 le proporciona las herramientas para automatizar completamente el ciclo de construcción-implementación-prueba.
- SQL2012 y Visual Studio vNext amplían las capacidades de los proyectos de bases de datos. Conozca VS2010 ahora y tendrá una ventaja inicial en las herramientas de desarrollo de bases de datos de próxima generación.