¿Por qué debería usar Visual Studio 2010 sobre SSMS para el desarrollo de mi base de datos?

Visual Studio 2010 presenta proyectos de bases de datos y toda una serie de características relacionadas que supuestamente facilitan el desarrollo de bases de datos. He usado SQL Server Management Studio (SSMS) durante muchos años para desarrollar mi base de datos sin problemas.

• ¿Por qué debería molestarme con VS2010 cuando SSMS funciona para mí? ¿Qué, específicamente, hace mejor que SSMS?
• Pero tal vez mi premisa es incorrecta y SSMS aún prevalece sobre VS para el desarrollo de bases de datos. Si es así, ¿de qué maneras específicas es eso cierto?

En realidad, estaba un poco decepcionado con VS2010, para ser honesto. Creo que un script de tabla de creación de la vieja escuela y archivos para procedimientos almacenados son más fáciles de trabajar. Si necesita administración de esquemas, puede obtener Redgate SQL Compare Pro por unos cientos de dólares.

Si realmente necesita una herramienta de modelado de base de datos, Powerdesigner o incluso Erwin hacen un trabajo mucho mejor, aunque no son particularmente baratos.

Aunque prefiero SSMS, he usado ambos. Algunos pros y contras:

• SSMS tiene una interfaz de usuario que 'simplemente funciona' bien para el desarrollo de SQL. Simplemente construir y usar scripts de creación es mucho más conveniente que los aros que VS2010 te obliga a saltar. Mucho, mucho más flexible (+ SSMS).

• VS2010 tiene administración de esquema básico (es decir, generación de script de diferencia / parche) (+ VS2010). Sin embargo, no es tan bueno y tiene algunos defectos. Por ejemplo, coincide con las restricciones de nombre. Si tiene restricciones de verificación o predeterminadas en una columna sin nombrarlas, SQL Server genera un nombre aleatorio detrás de escena. Esto confundirá VS2010 si instala el script en una máquina diferente, ya que las restricciones pueden tener nombres diferentes. Redgate es más barato y mejor. (+ VS2010, pero defectuoso).

• VS2010 es realmente torpe: debe tener un archivo para cada tabla u otro objeto DB. Esencialmente tienes que hacer las cosas al estilo VS2010, lo cual es bastante engorroso. (- VS2010)

• VS2010 también es algo frágil y la integración de control de fuente es escasa. Incluso en una base de datos simple, cada tabla, restricción, procedimiento almacenado, índice y otro objeto de la base de datos es su propio archivo. Los archivos se agregan al proyecto todo el tiempo, mucho más rápido que un proyecto de programación típico con (digamos) C #. Con una concurrencia optimista, tiende a eliminar silenciosamente los archivos del proyecto a medida que los registros no se sincronizan. Incluso con una buena disciplina de equipo, los comentarios de la UI sobre el estado son muy pobres. Esto sería un desastre en un modelo complejo. (-VS2010: casi considero que es un defecto espectacular para un gran proyecto).

• SSMS viene con SQL Server: no se puede superar el precio (+ SSMS).

• VS2010 todavía no tiene un repositorio adecuado como (por ejemplo) PowerDesigner u Oracle Designer. No puede consultar fácilmente el modelo de datos sin instalarlo en una base de datos. (- VS2010).

En general, calificaría VS2010 sobre un B-. Fue torpe en un proyecto de base de datos relativamente simple con dos tablas de hechos y alrededor de 15 dimensiones.

El modelo de datos más grande que hice fue para un sistema de gestión de casos judiciales, que tenía alrededor de 560 tablas. No recomendaría VS2010 para un proyecto de ese tamaño (lo hice en Oracle Designer). Básicamente, trata de ser inteligente y el paradigma realmente no funciona tan bien. Estás mejor con una herramienta de modelado de primer nivel como PowerDesigner o simplemente usando crear scripts de tabla a mano.

SSMS es simple y confiable pero manual. Tiene un control prácticamente infinito sobre cómo desea administrar el modelo. Combínelo con un administrador de esquemas como Redgate SQL Compare y tal vez una herramienta de modelado decente como PowerDesigner y tendrá un paquete mucho mejor que VS2010.

Resumen No estoy seguro de poder citar ninguna característica o beneficio asesino aparte de (quizás) la integración con soluciones VS que contienen otros proyectos. Si ya tiene VS2010 premium o ultimate, obtendrá una herramienta de desarrollo de base de datos algo defectuosa con su cadena de herramientas .Net. Integrará proyectos DB en su solución VS, por lo que puede usarla para hacer scripts de implementación de sproc al menos.

Sin embargo, VS no tiene una herramienta de modelado para hablar, por lo que PowerDesigner o incluso Erwin son mejores en ese aspecto. La gestión del esquema de Redgate es mucho mejor y SQL Compare Pro es bastante barato (alrededor de £ 400 IIRC). IMHO SSMS funciona mucho mejor para el desarrollo de T-SQL, pero ciertamente puede hacerlo con VS2010.

VS2010 premium no es mucho más barato que una herramienta de modelado de bases de datos de primer nivel y VS2010 ultimate es al menos igual de costoso. A expensas de una estrecha integración con su proyecto VS, probablemente podría mejorar con herramientas de terceros.

Una alternativa

Supongo que uno no debería excavar demasiado VS2010 sin sugerir al menos una alternativa y describir sus ventajas y desventajas. A los efectos de esto, asumiré un gran proyecto. Aunque actualmente trabajo principalmente en A / P, he estado involucrado en un proyecto de más de 100 años de personal donde hice el modelo de datos (y algunos trabajos de desarrollo) y un par de otros en el rango de 10 años de personal, donde trabajé principalmente como analista o desarrollador. Principalmente trabajo en sistemas de almacenamiento de datos en estos días, pero los proyectos más grandes eran principalmente aplicaciones. Según mis experiencias con diversas herramientas, aquí hay algunas sugerencias para una cadena de herramientas alternativa:

• VS2010 profesional o superior. Es posible que desee o no utilizar las funciones de gestión de proyectos premium o ultimate.
• Subversion, AnkhSVN y TortoiseSVN: mejor que TFS cualquier día y juega muy bien con VS. También es bastante susceptible de cultivar repositorios locales para flujos de trabajo de desarrollo concurrentes.
• SSMS para el desarrollo de T-SQL: la gestión de proyectos y la integración SC no son tan buenas, pero funcionan bien para el trabajo de desarrollo de bases de datos.
• Proyecto VS2010 DB para el seguimiento de archivos sproc: un poco torpe si está utilizando SSMS pero funciona bien. También generará scripts de implementación.
• PowerDesigner: mucho mejor para modelar una base de datos y administrar elementos de esquema de base de datos. También hace UML si quieres entrar mucho en MDA. Si desea manejar su diseño de base de datos desde un modelo de objetos, puede considerar Sparx EA en su lugar. Hace el mejor trabajo de Meta CASE (metamodelo extensible) de cualquier herramienta CASE que he visto, aunque su modelado de base de datos deja mucho que desear.
• SQL Compare pro: use esto para generar scripts de parches de base de datos o para probar scripts de parches manuales (consulte 1 a continuación).
• Framemaker: características de groupware mucho más estables y mejores que Word si tiene varios analistas trabajando en una especificación. También es compatible con la inclusión condicional, por lo que puede tener versiones versionadas de una especificación con cambios WIP ocultos. MIF y MML facilitan bastante la integración de documentos API y diccionarios de datos en los documentos de especificaciones. Es bastante útil hacer esto, ya que puede hacer una referencia cruzada en la especificación. Las anclas de etiquetas textuales hacen que las referencias cruzadas sean estables en las reimportaciones. También puede usar TCS para obtener el documento de una sola fuente en formato PDF, HTML y CHM.
• Rastreador de problemas de código abierto: muchos buenos de código abierto (por ejemplo, TRAC, Bugzilla, por nombrar una pareja que he usado). Los de código abierto son más fáciles de modificar o integrar en un flujo de trabajo personalizado y no se puede superar el precio.
• NUnit u otras herramientas de prueba: las herramientas de prueba automatizadas que sean más apropiadas para sus requisitos.
• Cualquier cosa menos proyecto de EM: considerado dañino. El proyecto de MS tiene una visión muy interna y obliga a los planes del proyecto a un modelo que no represente efectivamente la incertidumbre, el riesgo o las dependencias de las partes interesadas u otros terceros (ver 2 a continuación).

Pros: Mejor modelado de bases de datos y administración de esquemas que VS2010, mejor sistema de control de versiones, más fácil de personalizar el flujo de trabajo de construcción y proyecto, mejor administración de especificaciones y documentación.

Contras: Más esfuerzo para integrar herramientas, integración limitada de DB en el proceso de construcción.

Suposiciones: Asume que el control del proceso de cambio / lanzamiento es más importante que la administración de lanzamientos automatizada o estrechamente integrada para esquemas de base de datos. También supone que la gestión automatizada del esquema de base de datos no es 100% confiable.

No es terriblemente de alta tecnología o está hábilmente integrado, pero para un proyecto complejo, probablemente esté más interesado en el control que en las lindas funciones automatizadas. Yo diría que está mejor con un conjunto de las mejores herramientas de la raza y cualquier script de creación y prueba de elaboración casera es necesario para integrarlos. Solo trate de mantener la compilación (a) relativamente simple de entender y (b) totalmente automatizada.

1. Control de calidad en parches DB. En un esquema grande, es posible que desee tener un proceso de parcheo manual para sistemas en vivo, particularmente si los parches involucran migración de datos. Por ejemplo, puede ser deseable tener secuencias de comandos de avance y retroceso para admitir la reversión de un cambio si es necesario. En este caso, querrá tener una instalación para probar que el parche realmente funciona correctamente. Si administra el esquema de la base de datos en un repositorio, puede probar los scripts configurando antes de las bases de datos y generando una base de datos de referencia desde el repositorio. Ejecutar el script de parche en la base de datos anterior debería sincronizarlo con el modelo de repositorio. Se puede utilizar una herramienta de comparación de esquemas para probar esto.

2. He realizado mucho más trabajo de almacenamiento e integración de datos que el desarrollo de aplicaciones a medida últimamente, por lo que encuentro esto con más frecuencia de lo que lo hará un equipo de desarrollo en la mayoría de los casos. Sin embargo, las herramientas y metodologías de gestión de proyectos hacen un trabajo muy pobre en la gestión de partes interesadas externas. En un proyecto de integración como un almacén de datos, realmente quiero ver una herramienta de administración de proyectos que realmente empuje las dependencias externas (es decir, las que no controlo) frente a la administración del programa. En cualquier proyecto de integración no trivial, las dependencias externas son, con mucho, los principales impulsores del tiempo perdido.

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?

• Ellos no son perfectos . Pero si conoce las limitaciones y las áreas problemáticas, puede solucionarlas.
• Los movimientos de datos complejos aún requieren cuidado y atención, pero se atienden con scripts de implementación previos / posteriores.

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.

VS puede parecer excelente si no conoce SSMS o ha utilizado herramientas de terceros. Las brechas en VS se destacan si utiliza las herramientas de Red Gate para la comparación de esquemas, etc. Y los complementos SSMS gratuitos también.

Los bits de control de origen son engañosos: lo que está en la base de datos de producción es su copia de referencia. No es lo que está usando el desarrollador. Ver

• https://stackoverflow.com/q/1597085/27535
• https://stackoverflow.com/q/4433153/27535

Uso Visual Studio ampliamente (bueno, BIDS) para el diseño de informes SSRS y paquetes SSIS. Tampoco podría hacerlo muy bien, si es que lo hice, en Management Studio. Visual Studio es un entorno de desarrollo mucho más completo e integrado, y también se conecta mucho mejor a los sistemas de control de código fuente. ¡Y todo eso se refleja en el precio!

Para ser honesto, mi voto va directamente a SQL Server Management Studio para el diseño, desarrollo y administración (obviamente) de la base de datos. Es más fácil escribir:

create table newTable
(
    someId int identity(1, 1) not null primary key clustered,
    ...... you get the idea
)

Luego haga clic en todos los lugares correctos. SSMS es un gran diseño y es una maravilla para trabajar. Y soy un desarrollador de software .NET por naturaleza. Pero cuando se trata de codificación y diseño de bases de datos, elegiré SSMS 11 de cada 10 veces.

No existe una mejor práctica, pero con el proyecto de base de datos VS 2010 y el controlador de código fuente (VSS 2010, Subversion, etc.) puede versionar su base de datos.

Recomiendo que primero diseñe su base de datos directamente en SSMS. Una vez que su base de datos esté casi lista, impórtela en un proyecto de base de datos VS 2010. Una vez que se realiza la importación, siempre debe agregar un nuevo script a su proyecto de base de datos para realizar un seguimiento de todas las modificaciones. Puede usar la función de comparación del proyecto de base de datos para obtener todos los cambios del servidor de desarrollo e importar todos esos scripts directamente en su proyecto. Ahora solo tiene que "confirmar" su cambio en su controlador de código fuente.

Con este método, puede tener una base de datos versionada. Puede detectar la versión de cada modificación y revertir sus cambios.

Esta no es la única ventaja. Con este tipo de proyecto, puede comparar cualquier base de datos de su proyecto para realizar un script de los cambios y con el símbolo del sistema de SQL PowerShell, puede actualizar todas sus bases de datos con el mismo script: este script es un esquema XML de su base de datos. Ejecutará solo los comandos necesarios para actualizar sus bases de datos. También tiene la posibilidad de realizar pruebas unitarias en su base de datos. Otro buen artículo para el proyecto de base de datos está disponible aquí . Con la función de implementación, puede tener pre-script y post-script. Con esos scripts puede tener validación ni insertar datos en las tablas de su sistema.

Aquí hay un buen procedimiento paso a paso para el proyecto de base de datos.

Yo uso SSMS más que VS2010 porque está allí cuando instalo SQL Server. Eso es probablemente lo más importante por qué SSMS se usa más que VS2010, en mi humilde opinión.

También descubrí que proveedores como Red-Gate están lanzando herramientas que se integran con SSMS y no necesariamente VS2010. Esto puede ser positivo porque le permite mejorar SSMS donde Microsoft no lo ha hecho. Un ejemplo de esto es el control de código fuente SQL de Red-Gate, que es un complemento de SSMS que le permite conectar SSMS al sistema de control de código fuente de su empresa, ya sea Visual Team Foundation o lo que sea. VS2010 tiene esto incorporado, pero en comparación con el precio de la herramienta de Reg-Gate, acabo de ahorrar un montón de dinero sin tener que comprar VS2010.

Creo que, en general, todo se reduce a la preferencia, trabajas con aquello con lo que te sientes cómodo. Si estás entrenando a una nueva persona y la entrenas en VS2010, eso se convertirá en su preferencia porque saben cómo manejarlo.

Si comenzó a jugar con SQL Server 2012, es posible que haya notado que SSMS está obteniendo la composición de VS2010 de forma lenta pero segura. Así que eventualmente no podrás distinguir la diferencia entre ellos.