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


42

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?

2
De las respuestas acumuladas hasta ahora, sospecho que los encuestados no están utilizando ninguna de las herramientas de la base de datos VS2010 de la manera prevista.
Mark Storey-Smith

2
@ MarkStorey-Smith - Sí, y voy a sacudir a todos la próxima semana con mi respuesta. De lo que he aprendido y usado hasta ahora, VS 2010 es la herramienta para el desarrollo de bases de datos.
Nick Chammas el

En realidad, ya tenía proyectos de bases de datos en versiones anteriores de Visual Studio, pero solo estaban disponibles en las ediciones Premium, IIRC.
gonsalu

1
Las versiones anteriores eran muy diferentes.
Mark Storey-Smith

Solo uso SSMS. SSMS es totalmente capaz de hacer lo que hay que hacer. Nuestro servidor no necesita saber qué hay allí ...
Asken

Respuestas:


27

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.


Gracias por actualizar su respuesta con todos estos detalles. Es mucho más valioso ahora.
Nick Chammas el

2
No estoy de acuerdo en que un archivo por objeto sea engorroso. No es la forma VS2010, es el control de fuente 101. No define múltiples clases de C # en un solo archivo, ¿verdad?
Mark Storey-Smith

2
Honestamente, no te sigo. En primer lugar, las herramientas administran esos archivos por usted, no agrega una sobrecarga a mi productividad. En segundo lugar, las tablas, las claves, los índices y las restricciones están separados porque a) son objetos separados, lógica y físicamente b) a menudo los manipula de forma aislada, por ejemplo, eliminando y recreando índices como parte de un refactor que involucra el movimiento de datos.
Mark Storey-Smith

1
Declaraciones generales como "las herramientas administran los archivos por usted" no son muy útiles, ya que mi observación es que claramente no lo hacen, al menos de manera no confiable. VS2010 podría funcionar bien para un solo usuario; no funcionó muy bien para un equipo. Mi experiencia es que un socio de oro de MS tuvo problemas para administrar un mercado de datos contables simple con esto. No fue la gente.
Preocupado por

2
@ConcernedOfTunbridgeWells, por favor, no vean mis comentarios como antagonistas o argumentativos de ninguna manera, esa no es mi intención. Estoy muy interesado en saber por qué VS2010 no se está adoptando más ampliamente, ya que a menudo hago un caso para que los equipos lo exploren. Si puede dedicar tiempo para discutir en más detalle , me interesaría escuchar sus pensamientos.
Mark Storey-Smith

19

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.

Respuesta útil con algunas advertencias: 1) Se perdió un criterio "Está desarrollando aplicaciones independientes que se envían a sitios de clientes (es decir, hay varias copias de la misma base de datos en estado salvaje y se están creando nuevas [vacías]) / vendido todo el tiempo) "2) Ha respondido por qué deberíamos tratar una base de datos como código y administrar los ciclos de desarrollo, construcción e implementación (con lo que ya estoy de acuerdo). No veo una razón convincente en su respuesta de por qué deberíamos usar VS2010 como mecanismo para lograrlo. +2 (respuesta reflexiva) y -1 (sin responder la pregunta real)
Andrew Bickerton

2
¿Qué "IDE enriquecido" necesita para un script SQL?
gbn

1
Los beneficios de los ciclos automatizados de construcción-implementación-prueba se ven más adelante. La parte automatizada de una implementación en vivo que limitaría a ser "sin intervención", es decir, no requiere ningún paso manual.
Mark Storey-Smith

1
Aparte de eso, sus argumentos para la integración tienen algún mérito. ¿Qué tan bien funciona en el caso general? He tenido problemas con él, pero me atrevo a decir que se puede hacer que funcione.
Preocupado por

2
@ Nick, lo haré por ti :-)
Jack Douglas

7

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


1
Tengo que estar de acuerdo con esto: puede hacer el diseño / desarrollo de DB y la administración de esquemas con VS2010, pero hay cadenas de herramientas de terceros que lo hacen de esta manera, mucho mejor.
Preocupado por

1
¿Por qué tomarías la producción como tu copia de referencia? Creo que es una mala práctica, y probablemente también una señal de que su control de fuente está roto. ¿Por qué su código de base de datos no debería pertenecer al ciclo de vida de desarrollo como todo lo demás?
Nick Chammas

@ NickChammas: me refiero a una copia restaurada de la producción. En mi tienda actual, lo que está en el control de origen no coincide con el DB en vivo. En mi último, similar para otros equipos. Lo que se despliega a través de un script de cambio no es lo que los desarrolladores están trabajando en ...
GBN

6

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!


6

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.


En Visual Studio, escribe su tabla DDL exactamente de la misma manera. ¿Estás pensando en otra cosa?
Nick Chammas

1
@ Nick, probablemente lo dije mal. Sé que puedes hacer eso en VS, pero lo mío es que es bueno tener una herramienta dedicada para esa tarea específica (y grande) a la mano. Definitivamente soy una bestia de hábito, y he hecho de SSMS mi hábito. :)
Thomas Stringer

2
De Verdad? Las capacidades de la solución / proyecto SSMS parecen haber sido agregadas por un interno 2 semanas antes del lanzamiento.
Mark Storey-Smith

1
@ MarkStorey-Smith es la pregunta sobre cómo SSMS realmente no tiene soporte para proyectos / soluciones y eso es importante para permitir que los equipos trabajen bien en un IDE en todos los ámbitos.
jcolebrand

3
Una respuesta sería que SSMS es una herramienta de administración de bases de datos, VS2010 es una herramienta de desarrollo de bases de datos.
Mark Storey-Smith

5

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.


44
No es así como se debe hacer el desarrollo de la base de datos en VS2010, parece que has perdido el punto un poco. 1) ¿Por qué una tierra diseñaría una base de datos nueva en SSMS y luego importaría a VS? 2) No tiene que "agregar siempre un nuevo script a su proyecto de base de datos" para realizar un seguimiento de los cambios. 3) Los scripts no son un "esquema xml" de su base de datos.
Mark Storey-Smith

¿Alguna vez has probado el proyecto de base de datos? 1 - Porque solo puedes importar tu base de datos una vez, así que si no quieres hacer un script, haz lo máximo que puedas en SSMS para el primer borrador de la base de datos. 2- Tienes razón, puedes seguir los cambios con la herramienta de comparación de VS2010 y VS2010 lo generará por ti. 3- Pruebe el proyecto de base de datos, cuando implemente su proyecto de base de datos obtendrá un esquema XML de su base de datos para actualizar sus bases de datos de producción.
Nico

2
Sí, desde las primeras y más dolorosas versiones . Realmente importaría una vez, pero sincronizaría muchas (no es que alguna vez tenga que hacerlo, a menos que continúe trabajando fuera del entorno). Una descripción más precisa de lo que se refiere como un script de 'Esquema XML' es que las herramientas mantienen un metamodelo basado en xml de la base de datos, que la herramienta de implementación de línea de comando usa para crear los comandos necesarios para actualizar una base de datos de destino .
Mark Storey-Smith

2

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.