Migración de esquemas: herramientas de datos de SQL Server vs Liquibase y Flyway


11

Puede parecer una pregunta estúpida, pero he estado buscando soluciones de código abierto para la migración de esquemas, a saber, Liquibase y Flyway.

Sin embargo, mi jefe me dijo que las herramientas de datos de SQL Server (SSDT) ​​logran el mismo trabajo. No estoy seguro si estoy de acuerdo, pero puedo encontrar muy poco en Internet que lo compare directamente con Liquibase y / o Flyway.

Mi opinión es que SSDT es una herramienta de desarrollo, modelado de datos y diseño para SQL Server y también es compatible con la comparación de esquemas (y la generación de scripts) y el control de código fuente. Aborda un problema diferente, aunque puede haber cierta superposición con Liquibase / Flyway en algunos aspectos de la migración de esquemas. Pero como herramienta general de migración de esquemas, Liquibase y Flyway son herramientas totalmente dedicadas, mientras que SSDT es más para el diseño y desarrollo de una base de datos.

Cualquier opinión sería muy apreciada, incluso si es solo para decir que no hay comparación y SSDT no es una herramienta de migración de esquema per se.

Respuestas:


17

SSDT es comparable a Liquibase / Flyway ya que hace lo que hacen pero adoptando un enfoque diferente. Con SSDT, tiene el entorno de desarrollo para obtener cosas como ir a la definición, encontrar referencias e intelli-sense, así como la capacidad de compilar un proyecto en un dacpac y luego implementar ese dacpac en una base de datos.

La forma SSDT (y la forma de comparación sql redgate) para hacer una liberación es declarar lo que desea, por lo que si desea cambiar una tabla que se ve así:

create table a(id int)

a una mesa que se parece a:

create table a(id int, another_column varchar(12))

con SSDT, simplemente cambia la definición de la tabla a la segunda y deja que SSDT se preocupe por cómo actualizarla (¿puede hacer una tabla alternativa, agregar una columna o cambia el orden de la columna, por lo que deberá reconstruir la tabla, etc.)?

Con Liquibase (DbUp, ReadyRoll, métodos manuales, etc.), lo que debe hacer en este caso es escribir la tabla alter usted mismo y asegurarse de ejecutar los scripts en el orden correcto, considere este escenario:

  1. Lanzamiento 1 - crear columna hola en la mesa
  2. Versión 2 - renombra la columna hola a joe_blogs
  3. Versión 3 - renombra la columna joe_blogs a hola
  4. Versión 4 - crear columna joe_blogs

Si se pierde alguno de los lanzamientos, ninguno de los siguientes puede continuar.

Beneficios de los scripts de actualización (Liquibase, DbUp, etc.):

  • Tienes control total sobre los scripts
  • Los DBA / Desarrolladores están acostumbrados a esto

Beneficios de comparar / fusionar (SSDT, Redgate SQL Compare):

  • No tiene que escribir scripts de actualización
  • Es fácil llegar a cualquier versión específica, solo compare y combine esa versión

Inconvenientes de los scripts de actualización:

  • Debe ejecutarse en orden
  • Confíe en los humanos sin cometer errores
  • Puede ser lento, especialmente si tiene muchos cambios
  • A menos que su equipo sea muy disciplinado, las bases de datos en diferentes entornos (desarrollo, prueba, preparación, producción, etc.) a menudo no están sincronizadas, lo que invalida cualquier prueba
  • La degradación de una versión significa escribir el reverso de todos los scripts que ya ha escrito

Inconvenientes del uso de comparar / fusionar:

  • Las herramientas no son 100% confiables, quizás injustamente
  • SSDT requiere un proyecto que funcione, muchas bases de datos tienen código que realmente no se compila ni ejecuta (piense en tablas descartadas, pero no en procedimientos, etc.), lo he visto en aproximadamente 8/10 bases de datos que heredé :)
  • Muchos DBA / desarrolladores dudan en abandonar el desarrollo en SSMS / bloc de notas

Personalmente, realmente creo que SSDT es un entorno de desarrollo profesional y significa que puedo concentrarme en escribir códigos y pruebas útiles en lugar de escribir scripts de actualización que son en sí mismos solo un medio para un fin.

Pediste opiniones, así que ahí vas :)

ed


1
¿SSDT funciona con algo más que SQL Server? por ejemplo, Postgres?
a_horse_with_no_name

3
No hay "herramientas de datos del servidor SQL" :)
Ed Elliott

1
Por qué no? El paquete SSIS puede transferir en su mayoría todas las fuentes ODBC
a_vlad

A menos que haya entendido mal, ¿creo que estamos hablando de administrar el esquema de la base de datos en lugar de crear paquetes ssis? Feliz de ser corregido :)
Ed Elliott

1
SSIS está destinado a mover datos y, como tal, admite conexiones a una gran variedad de sistemas. SSDT está destinado al desarrollo y mantenimiento de proyectos de bases de datos de SQL Server. Tiene un proceso de compilación que verifica la compatibilidad de las secuencias de comandos con la versión objetivo de SQL Server y todas las referencias, procesos, etc. para la sintaxis de T-SQL.
Dave

2

Acabo de recargar la respuesta de previsión.

La mayor diferencia descrita en el sitio web de Flyway en el lugar central:

Resuelve solo un problema y lo resuelve bien. Flyway migra su base de datos, por lo que ya no tiene que preocuparse por eso.

Visual Studio + SSDT + SSIS = herramienta ETL de potencia completa, con un solo inconveniente real: solo funciona bajo Windows. Necesita Windows + SQL Server para ejecutar paquetes, pero funciona principalmente con todas las fuentes.

Para transferir / migrar datos, muchos productos en el mercado. Comercial, de código abierto, comunidad / express y etc.

Para migrar código, no todo es tan bueno. Incluso si el software promete "convertir desencadenantes, procedimientos y funciones sin problemas", de hecho, solo simple, la mayoría de la migración de código, manual.


2

He trabajado con herramientas de datos del servidor SQL y flyway. Usando SSDT, obtengo las siguientes ventajas:

  1. Puedo compilar el proyecto de la base de datos ... lo que significa que no hay temor de soltar una columna a la que hace referencia una vista, función o procesos almacenados. Esta es una gran característica, porque en el pasado, descubrimos tales errores solo después del lanzamiento
  2. Después de una compilación exitosa, SSDT genera lo que se conoce como "DACPAC". Piense en esto un msi con una versión.

  3. Un dacpac dado, con dicha versión 5, se puede aplicar a una base de datos que se encuentra en Dacpac versión 1,2,3,4 o 6,7,8, etc. Si se aplica a 1-4, la base de datos se actualizará. Si se aplica a 6,7, etc., la base de datos se degradará / revertirá. Habrá advertencias, si habrá pérdida de datos, que pueden suprimirse. Por lo tanto, obtenemos una excelente función de reversión, que no está disponible con otras herramientas como flyway, etc. Con flyway, uno tiene que proporcionar un nuevo conjunto de scripts para retroceder.

  4. DACPAC aplica todos los cambios en una transacción; lo que significa que si hay 5 cambios de tabla en la actualización y uno de ellos falla, la transacción completa se revierte. Flyway también admite esto, pero para cada archivo.

Sin embargo, SSDT y DACPAC son específicos de Microsoft SQL Server; Flyway se puede utilizar para una variedad de bases de datos.

Entonces, en resumen, si está utilizando solo SQL Server, debería ser una decisión bastante fácil elegir SSDT y DACPAC.

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.