database - source - Estructura de la base de datos y control de origen: mejores prácticas

source control sql server database (10)

Fondo

Llegué de varios años trabajando en una empresa donde todos los objetos de la base de datos se almacenaban en control de fuente, un archivo por objeto. Teníamos una lista de todos los objetos que se mantuvieron cuando se agregaron nuevos elementos (para permitirnos ejecutar scripts en orden y manejar dependencias) y un script VB que se ejecutó para crear un script grande para ejecutarse en la base de datos.

Todas las tablas eran ''crear si no existe'' y todos los SP, etc., se soltaron y recrearon.

Hasta el presente y ahora estoy trabajando en un lugar donde la base de datos es el maestro y no hay control de fuente para los objetos DB, pero sí usamos las herramientas de redgate para actualizar nuestra base de datos de producción (SQL compare), que es muy útil, y requiere poco trabajo.

Pregunta

¿Cómo manejas tus objetos DB? Me gusta tenerlos bajo control de código fuente (y, como estamos usando GIT, me gustaría poder manejar conflictos de combinación en las secuencias de comandos, en lugar de DB), pero voy a estar presionada para pasar la facilidad de usar SQL se compara para actualizar la base de datos.

Realmente no quiero que actualicemos guiones en GIT y luego usar SQL compare para actualizar la base de datos de producción de nuestro DEV DB, ya que prefiero tener ''una versión de la verdad'', pero realmente no quiero consiga volver a escribir un poco de software personalizado para agrupar todo el conjunto de secuencias de comandos.

Creo que la edición de la base de datos visual studio puede hacer algo similar a esto, pero no estoy seguro si tendremos el presupuesto para ello.

Estoy seguro de que esto se ha pedido hasta la muerte, pero no puedo encontrar nada que parezca tener la respuesta que estoy buscando. Similar a esto, pero no exactamente lo mismo:

Cuáles son las mejores prácticas para las secuencias de comandos de bases de datos bajo control de código

Comencé una recompensa, ya que estoy interesado en solicitar más opiniones. Las respuestas aquí son buenas, pero creo que realmente debería haber una manera más fácil.

Gracias por todas las excelentes respuestas, todas tienen sus méritos, así que voy a tomar el voto más alto, pero aplaude por todas las aportaciones.

Actualmente mantengo un diseño de base de datos en una herramienta de modelado (DeZine for Databases) y lo almacena bajo control de fuente. Dentro de mi diseño de tabla agrego una tabla con dos filas que tienen el número de versión del esquema y de los datos de referencia, esto se actualiza cada vez que se cambia / suelta la base de datos (los usuarios no tienen acceso a esta tabla).

Los datos de referencia se mantienen en una hoja de cálculo de Excel (también bajo control de fuente) que puede generar una secuencia de comandos SQL de instrucciones INSERT para rellenar nuevas bases de datos.

Cuando se requiere una nueva versión, se envían la secuencia de comandos de esquema, la secuencia de comandos de datos de referencia y un paquete de instalación. El paquete de instalador cambia el nombre de la base de datos anterior, crea una nueva base de datos a partir del script e importa los nuevos datos de referencia (que también pueden haber cambiado). Los datos del usuario se copian desde la base de datos anterior (renombrada) a la nueva.

Esto tiene la ventaja de que cuando las cosas van mal puede volver a la base de datos original ya que no se ha modificado.

Eche un vistazo a esta serie de cinco partes sobre los principios y prácticas del control de versiones de bases de datos (por K. Scott Allen):

Las cinco partes son importantes, pero básicamente la idea es tener una línea base y luego cambiar las secuencias de comandos (con una tabla de versiones). Actualizar la base de datos significa aplicar scripts de modificación "arriba" de la versión actual. Y esta estrategia es muy amigable para VCS (sin conflictos).

En el trabajo hacemos un uso intensivo de una poderosa herramienta que viene como parte de ActiveRecord (que es el ORM predeterminado que viene con el marco web de Rails llamado Migrations .

Una migración básica se vería así:

class AddSystems < ActiveRecord::Migration def self.up create_table :systems do |t| t.string :name t.string :label t.text :value t.string :type t.integer :position, :default => 1 t.timestamps end end def self.down drop_table :systems end end

Se ha creado una migración para cada cambio en la base de datos, y se crean en orden secuencial por marca de tiempo. Puede ejecutar métodos predefinidos para ejecutar estas migraciones en el orden correcto, de modo que siempre se pueda crear y / o retrotraer su base de datos. Algunas de las funciones están a continuación:

rake db:migrate #run all outstanding migrations rake db:rollback #roll back the last run migration rake db:seed #fill the database with your seed data

Las migraciones tienen métodos para crear tablas, eliminar tablas, actualizar tablas, agregar índices, etc. El conjunto completo. Las migraciones también agregan automáticamente una columna de id , y la sección t.timestamps genera automáticamente un campo "created_at" y un campo "updated_at".

La mayoría de los lenguajes tienen instalaciones ORM como estas, y permiten que la base de datos se mantenga en un estado de código, lo cual es fácil de entender para los desarrolladores, además de ser lo suficientemente simple para que los DBA puedan usarla y mantenerla.

Hay una herramienta especial para esto exacto. Se llama Wizardby :

... integración continua de bases de datos y marco de migración de esquemas

Wizardby Workflow http://octalforty-wizardby.googlecode.com/svn/trunk/docs/img/database_versioning_with_wizardby.png

No estoy muy familiarizado con RedGate toolkit, pero si es similar a dbGhost , debe haber una utilidad que le permita crear los objetos de la base de datos a los archivos uno por objeto. En este caso, sugeriría lo siguiente:

agregue un trabajo diario (o parte de una construcción) para realizar ingeniería inversa de la base de datos DEV en la estructura de directorios
luego compárelo con lo que tiene en el repositorio (por medio de diff simple), y BÁSICAMENTE FAIL el trabajo de compilación e informe el diff si hay alguno. Esto indicará que la estructura de la base de datos DEV ha cambiado y no se refleja en el control de fuente,
lo que indicará al desarrollador que agregue los cambios al control de origen (incluso use el archivo .diff reportado para esto)

Si tiene muchas bases de datos DEV (una por usuario o rama de desarrollo) y es demasiado engorrosa, probablemente una mejor combinación sería realizar dicha tarea en la versión STAGE (TEST justo antes de la versión) de la base de datos, momento en el que almacenaría el esquema PROD en el repositorio y lo actualizaría desde la ETAPA solo durante la fase de prueba previa a la liberación, donde se asegurará de que sus cambios de esquema también estén en el repositorio.

De esta forma, los desarrolladores pueden seguir trabajando de la manera habitual: primero cambie el esquema en la base de datos DEV y, con suerte, obtenga el equilibrio entre la flexibility y one truth que le gustaría.

En mi equipo agregamos cambios a VCS tan pronto como cambiamos la base de datos DEV, pero todavía tenemos esa tarea para comparar el esquema entre diferentes bases de datos (DEV, STAGE y PROD). Básicamente, seguimos lo que una vez respondí en ¿Cómo debería construir su base de datos desde el control de código fuente? .

Si ya está utilizando las herramientas de Red Gate, podría considerar usar SQL Source Control, que funciona junto con SQL Compare y SQL Data Compare para permitir que exista una versión de la verdad en el control de la fuente. Está en acceso anticipado en este momento, pero la mayoría de la funcionalidad está allí para probarse. Puede descargar esto de http://www.red-gate.com/Products/SQL_Source_Control/index.htm . Sin embargo, solo admite SVN y TFS por el momento. ¿Has estandarizado en GIT?

David (Product Manager en Red Gate)

Suponiendo que usa .NET Framework, eche un vistazo al Fluent Migrator y también al Headsing Code Podcast que habla sobre el proyecto.
El objetivo principal, como lo veo, es codificar fácilmente las migraciones a medida que realiza su codificación normal utilizando una interfaz fluida utilizando un enfoque independiente de la base de datos.

Está construido sobre el framework .net. y funciona con varios formatos de bases de datos, incluidos SQL Server, SqlLite y MySQL.

La ventaja de este enfoque es que vive con el resto de tu código y, por lo tanto, puede ser administrado por SCM.

Ejemplo:

[Migration(1)] public class CreateProjectsTable : Migration { public void Up() { Create.Table("Projects") .WithIdColumn() .WithColumn("Name").AsString().NotNullable() .WithColumn("Position").AsInt32().NotNullable() .WithColumn("Done").AsBoolean().NotNullable(); } public void Down() { Database.RemoveTable("Projects"); } }

Tenemos todos nuestros objetos de base de datos bajo control de fuente usando Visual Studio Database Edition (DBPro). Es una maravillosa herramienta que la versión controla nuestro esquema, hace compilaciones, validaciones, permite el análisis de códigos, comparaciones de esquemas, implementaciones, comparaciones de datos, refactorización, etc. Fue diseñado desde cero para ser un sistema de administración de bases de datos y control de versiones. Muy recomendable.

Este es el sitio de blog del arquitecto principal de DBPro: haga clic aquí

Tenemos un sistema en el que la base de datos es nominalmente maestra: dentro de nuestro sistema de control de origen, mantenemos una secuencia de scripts de "cambio de esquema" (archivos .sql), cada uno de los cuales es responsable de deshacer el cambio y aplicarlo idempotentemente. Cada script está simplemente numerado, por lo que tenemos 000.sql (que crea la base de datos y establece objetos estándar), 001.sql, etc.

Durante el desarrollo, un desarrollador escribe un script de cambio de esquema y lo ejecuta contra la base de datos de desarrollo. Se requiere cada cambio para agregar una fila en una tabla dba.change_info , que contiene el número de cambio y una breve descripción. Para revertir un cambio, uno solo puede ejecutar la primera sección del mismo. Para SQL Server, la idempotencia de la sección de reversión se maneja mediante el examen de sysobjects, etc., antes de emitir comandos DROP, similar a las construcciones "drop ... if exists". Es posible que los cambios de esquema necesiten realizar la migración de datos si se está modificando un modelo en lugar de simplemente agregarlos, y también se usan para mantener los datos de referencia.

Durante el proceso de lanzamiento, un DBA (somos una empresa pequeña, por lo que este es un rol asumido por uno de los desarrolladores) aplica los cambios de esquema para el lanzamiento a la base de datos de producción entre detener la versión anterior de las aplicaciones y comenzar los actualizados.

Este es todo un proceso bastante manual, pero cumple con requisitos como la migración de datos de un modelo a otro: por ejemplo, expandir un indicador booleano a un conjunto de opciones o convertir una asociación de varios a varios en muchos a muchos. Por lo general, esto no es algo que pueda generarse con simples herramientas de comparación de esquemas. También permite la separación de roles, aunque en la práctica todos tenemos acceso completo a la producción, hay suficiente desacoplamiento para que el "DBA" pueda leer y revisar los archivos .sql que se aplicarán en la producción.

En teoría, al menos, una base de datos completa (que contiene solo datos de referencia) podría construirse simplemente ejecutando todos los cambios de esquema para 000.sql en adelante. En la práctica, no hacemos esto regularmente, sino que copiamos nuestra base de datos de producción a dev y luego aplicamos los scripts de cambio antes de ejecutar las pruebas de regresión antes de una publicación. Esto sirve para probar los scripts de cambio en sí, pero solo es práctico con una base de datos de producción de tamaño mediano.

Utilizando un complemento SSMS de terceros ApexSQL Source Control , los objetos de la base de datos pueden ser automáticamente guiados y enviados a un repositorio remoto de Git, o incluso a uno local clonado, si usted prefiere trabajar con el repositorio local.

ApexSQL Source Control admite el sistema de control de fuente Git de fábrica. Eso significa que no necesita instalar ningún cliente adicional de Git. Además de esto, Branching and Merging está integrado y disponible a través de la interfaz de usuario de complemento.