¿Utiliza el control de origen para los elementos de su base de datos? [cerrado]

Siento que mi tienda tiene un agujero porque no tenemos un proceso sólido para versionar los cambios de esquema de nuestra base de datos. Hacemos muchas copias de seguridad para estar más o menos cubiertos, pero es una mala práctica confiar en su última línea de defensa de esta manera.

Sorprendentemente, esto parece ser un hilo conductor. Muchas tiendas con las que he hablado ignoran este problema porque sus bases de datos no cambian a menudo, y básicamente solo tratan de ser meticulosos.

Sin embargo, sé cómo va esa historia. Es solo cuestión de tiempo antes de que las cosas se alineen mal y algo desaparezca.

¿Hay alguna mejor práctica para esto? ¿Cuáles son algunas estrategias que te han funcionado?

Debe leer Obtenga su base de datos bajo control de versiones . Consulte la serie de publicaciones de K. Scott Allen.

Cuando se trata de control de versiones, la base de datos es a menudo un ciudadano de segunda o incluso de tercera clase. Por lo que he visto, los equipos que nunca pensarían en escribir código sin control de versiones en un millón de años, y con razón, pueden ser completamente ajenos a la necesidad de control de versiones en torno a las bases de datos críticas de las que dependen sus aplicaciones. No sé cómo puede llamarse a sí mismo ingeniero de software y mantener una cara seria cuando su base de datos no está exactamente bajo el mismo nivel riguroso de control de origen que el resto de su código. No dejes que esto te pase a ti. Obtenga su base de datos bajo control de versiones.

¿Las propias bases de datos? No

Las secuencias de comandos que las crean, incluidas las inserciones de datos estáticos, los procedimientos almacenados y similares; por supuesto. Son archivos de texto, están incluidos en el proyecto y se registran como todos los demás.

Por supuesto, en un mundo ideal, su herramienta de administración de bases de datos haría esto; pero solo tienes que ser disciplinado al respecto.

Me encantan las migraciones de Rails ActiveRecord. Resume el script de DML a ruby ​​que luego se puede versionar fácilmente en su repositorio de origen.

Sin embargo, con un poco de trabajo, podrías hacer lo mismo. Cualquier cambio DDL (ALTER TABLE, etc.) se puede almacenar en archivos de texto. Mantenga un sistema de numeración (o un sello de fecha) para los nombres de los archivos y aplíquelos en secuencia.

Rails también tiene una tabla de 'versión' en la base de datos que realiza un seguimiento de la última migración aplicada. Puedes hacer lo mismo fácilmente.

Consulte LiquiBase para administrar los cambios en la base de datos utilizando el control de origen.

Nunca debe simplemente iniciar sesión y comenzar a ingresar comandos "ALTER TABLE" para cambiar una base de datos de producción. El proyecto en el que estoy tiene una base de datos en cada sitio del cliente, por lo que cada cambio en la base de datos se realiza en dos lugares, un archivo de volcado que se utiliza para crear una nueva base de datos en un nuevo sitio del cliente y un archivo de actualización que se ejecuta en cada actualización que verifica el número de versión de su base de datos actual con el número más alto en el archivo y actualiza su base de datos en su lugar. Entonces, por ejemplo, las últimas actualizaciones:

if [ $VERSION \< '8.0.108' ] ; then
  psql -U cosuser $dbName << EOF8.0.108
    BEGIN TRANSACTION;
    --
    -- Remove foreign key that shouldn't have been there.
    -- PCR:35665
    --
    ALTER TABLE     migratorjobitems
    DROP CONSTRAINT migratorjobitems_destcmaid_fkey;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.108'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.108
fi

if [ $VERSION \< '8.0.109' ] ; then
  psql -U cosuser $dbName << EOF8.0.109
    BEGIN TRANSACTION;
    --
    -- I missed a couple of cases when I changed the legacy playlist
    -- from reporting showplaylistidnum to playlistidnum
    --
    ALTER TABLE     featureidrequestkdcs
    DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey;
    ALTER TABLE     featureidrequestkdcs
    ADD CONSTRAINT  featureidrequestkdcs_cosfeatureid_fkey
    FOREIGN KEY     (cosfeatureid)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    --
    ALTER TABLE     ticket_system_ids
    DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey;
    ALTER TABLE     ticket_system_ids
    RENAME          showplaylistidnum
    TO              playlistidnum;
    ALTER TABLE     ticket_system_ids
    ADD CONSTRAINT  ticket_system_ids_playlistidnum_fkey
    FOREIGN KEY     (playlistidnum)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.109'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.109
fi

Estoy seguro de que hay una mejor manera de hacerlo, pero hasta ahora me ha funcionado.

Si. El código es el código. Mi regla general es que necesito poder construir e implementar la aplicación desde cero , sin mirar una máquina de desarrollo o producción.

La mejor práctica que he visto es crear un script de compilación para eliminar y reconstruir su base de datos en un servidor provisional. Cada iteración recibió una carpeta para los cambios en la base de datos, todos los cambios fueron programados con "Drop ... Create". De esta manera, puede revertir a una versión anterior en cualquier momento señalando la compilación a la carpeta a la que desea realizar la versión.

Creo que esto se hizo con NaNt / CruiseControl.

SÍ, creo que es importante versionar su base de datos. No los datos, sino el esquema seguro.

En Ruby On Rails, el marco lo maneja con "migraciones". Cada vez que modifica la base de datos, crea un script que aplica los cambios y lo verifica en el control de origen.

A mi tienda le gustó tanto esa idea que agregamos la funcionalidad a nuestra compilación basada en Java usando scripts de shell y Ant. Integramos el proceso en nuestra rutina de implementación. Sería bastante fácil escribir scripts para hacer lo mismo en otros marcos que no son compatibles con las versiones de DB listas para usar.

Los nuevos proyectos de base de datos en Visual Studio proporcionan control de origen y scripts de cambio.

Tienen una buena herramienta que compara bases de datos y puede generar un script que convierte el esquema de uno en el otro, o actualiza los datos en uno para que coincida con el otro.

El esquema db se "tritura" para crear muchos, muchos archivos .sql pequeños, uno por comando DDL que describe la base de datos.

+ tom

Información adicional 30/11/2008

Lo he estado usando como desarrollador durante el año pasado y realmente me gusta. Hace que sea fácil comparar mi trabajo de desarrollo con la producción y generar un script para usar en el lanzamiento. No sé si faltan características que los DBA necesitan para proyectos de "tipo empresarial".

Debido a que el esquema se "tritura" en archivos sql, el control de origen funciona bien.

Uno de los problemas es que necesitas tener una mentalidad diferente cuando usas un proyecto db. La herramienta tiene un "proyecto db" en VS, que es solo el sql, más una base de datos local generada automáticamente que tiene el esquema y algunos otros datos de administración, pero ninguno de los datos de su aplicación, más su db de desarrollo local que utiliza para aplicación de desarrollo de datos de trabajo. Raramente conoce el db generado automáticamente, pero debe saber que está allí para poder dejarlo solo :). Este db especial es claramente reconocible porque tiene un Guid en su nombre,

VS DB Project hace un buen trabajo al integrar los cambios de db que otros miembros del equipo han realizado en su proyecto local / db asociado. pero debe dar un paso adicional para comparar el esquema del proyecto con su esquema de desarrollo de base de datos local y aplicar las modificaciones. Tiene sentido, pero parece incómodo al principio.

Los proyectos DB son una herramienta muy poderosa. No solo generan scripts, sino que pueden aplicarlos de inmediato. Asegúrese de no destruir su producción db con él. ;)

Realmente me gustan los proyectos VS DB y espero usar esta herramienta para todos mis proyectos de base de datos en el futuro.

+ tom

Exigir a los equipos de desarrollo que usen un sistema de administración de control de fuente de base de datos SQL no es la bala mágica que evitará que ocurran problemas. Por sí solo, el control de origen de la base de datos introduce una sobrecarga adicional ya que los desarrolladores deben guardar los cambios que han realizado en un objeto en un script SQL separado, abrir el cliente del sistema de control de origen, registrar el archivo de script SQL utilizando el cliente y luego aplicar los cambios a la base de datos en vivo.

Puedo sugerirle que use el complemento SSMS llamado ApexSQL Source Control . Permite a los desarrolladores mapear fácilmente los objetos de la base de datos con el sistema de control de fuente a través del asistente directamente desde SSMS. El complemento incluye soporte para TFS, Git, Subversion y otros sistemas SC. También incluye soporte para fuente que controla datos estáticos.

Después de descargar e instalar ApexSQL Source Control, simplemente haga clic con el botón derecho en la base de datos que desea controlar de versión y navegue al submenú ApexSQL Source Control en SSMS. Haga clic en la opción Vincular base de datos al control de origen, seleccione el sistema de control de origen y el modelo de desarrollo. Después de eso, deberá proporcionar la información de inicio de sesión y la cadena de repositorio para el sistema de control de origen que haya elegido.

Puede leer este artículo para obtener más información: http://solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/

Lo hago guardando scripts de creación / actualización y un script que genera datos de muestra.

Sí, lo hacemos manteniendo nuestro SQL como parte de nuestra compilación; mantenemos DROP.sql, CREATE.sql, USERS.sql, VALUES.sql y el control de versiones, para que podamos volver a cualquier versión etiquetada.

También tenemos tareas de hormigas que pueden recrear la base de datos cuando sea necesario.

Además, el SQL se etiqueta junto con el código fuente que lo acompaña.

El esquema más exitoso que he usado en un proyecto ha combinado copias de seguridad y archivos SQL diferenciales. Básicamente, haríamos una copia de seguridad de nuestra base de datos después de cada lanzamiento y haríamos un volcado de SQL para poder crear un esquema en blanco desde cero si fuera necesario también. Luego, cada vez que necesite hacer un cambio en la base de datos, agregará un script alternativo al directorio sql bajo control de versiones. Siempre prefijaríamos un número de secuencia o fecha al nombre del archivo, por lo que el primer cambio sería algo así como 01_add_created_on_column.sql, y el siguiente script sería 02_added_customers_index. Nuestra máquina de CI los verificaría y los ejecutaría secuencialmente en una copia nueva de la base de datos que se había restaurado desde la copia de seguridad.

También teníamos algunos scripts que los desarrolladores podían usar para reinicializar su base de datos local a la versión actual con un solo comando.

Controlamos la fuente de todos nuestros objetos creados en la base de datos. Y solo para mantener a los desarrolladores honestos (porque puede crear objetos sin que estén en el control de origen), nuestros dbas buscan periódicamente cualquier cosa que no esté en el control de origen y, si encuentran algo, lo sueltan sin preguntar si está bien.

Utilizo SchemaBank para controlar la versión de todos los cambios de esquema de mi base de datos:

• desde el día 1, importé mi volcado de esquema db
• comencé a cambiar mi diseño de esquema usando un navegador web (porque están basados ​​en SaaS / en la nube)
• cuando quiero actualizar mi servidor de base de datos, genero el script de cambio (SQL) y lo aplico a la base de datos. En Schemabank, me obligan a comprometer mi trabajo como una versión antes de que pueda generar un script de actualización. Me gusta este tipo de práctica para que siempre pueda rastrear cuando sea necesario.

La regla de nuestro equipo es NUNCA tocar el servidor db directamente sin almacenar primero el trabajo de diseño. Pero sucede que alguien podría verse tentado a romper la regla, por conveniencia. Importaríamos el volcado del esquema nuevamente en el banco de esquemas y lo dejaríamos hacer el diff y golpear a alguien si se encuentra una discrepancia. Aunque podríamos generar los scripts alternos para sincronizar nuestro diseño de esquemas y bases de datos, simplemente odiamos eso.

Por cierto, también nos permiten crear ramas dentro del árbol de control de versiones para que pueda mantener una para la puesta en escena y otra para la producción. Y uno para codificar sandbox.

Una herramienta de diseño de esquema basada en la web bastante ordenada con control de versiones y gestión de cambios.

Tengo todo lo necesario para recrear mi base de datos de metal desnudo, menos los datos en sí. Estoy seguro de que hay muchas maneras de hacerlo, pero todos mis scripts y demás están almacenados en subversion y podemos reconstruir la estructura de la base de datos y demás sacando todo eso de subversion y ejecutando un instalador.

Normalmente construyo un script SQL para cada cambio que hago, y otro para revertir esos cambios y mantener esos scripts bajo control de versión.

Luego tenemos un medio para crear una nueva base de datos actualizada bajo demanda, y podemos movernos fácilmente entre revisiones. Cada vez que hacemos un lanzamiento, agrupamos los scripts (requiere un poco de trabajo manual, pero rara vez es realmente difícil ), por lo que también tenemos un conjunto de scripts que pueden convertir entre versiones.

Sí, antes de decirlo, esto es muy similar a lo que hacen Rails y otros, pero parece funcionar bastante bien, así que no tengo problemas para admitir que descaradamente levanté la idea :)

Utilizo scripts SQL CREATE exportados desde MySQL Workbech, luego uso la funcionalidad "Exportar SQL ALTER" y termino con una serie de scripts de creación (numerados, por supuesto) y los scripts alternos que pueden aplicar los cambios entre ellos.

3.- Exportar script ALTER de SQL Normalmente, ahora tendría que escribir las instrucciones ALTER TABLE a mano, reflejando los cambios que realizó en el modelo. Pero puede ser inteligente y dejar que Workbench haga el trabajo duro por usted. Simplemente seleccione Archivo -> Exportar -> Forward Engineer SQL ALTER Script ... desde el menú principal.

Esto le pedirá que especifique el archivo CREATE de SQL con el que se debe comparar el modelo actual.

Seleccione el script SQL CREATE del paso 1. La herramienta generará el script ALTER TABLE para usted y puede ejecutar este script en su base de datos para actualizarlo.

Puede hacerlo utilizando el MySQL Query Browser o el cliente mysql. ¡Vola! ¡Su modelo y base de datos ahora se han sincronizado!

Fuente: MySQL Workbench Community Edition: Guía para la sincronización de esquemas

Todos estos scripts, por supuesto, están dentro bajo control de versiones.

Si siempre. Debería poder recrear la estructura de su base de datos de producción con un conjunto útil de datos de muestra cuando sea necesario. Si no lo hace, con el tiempo se olvidan los cambios menores para mantener las cosas en funcionamiento, entonces un día te muerden, a lo grande. Es un seguro que quizás no creas que necesitas, ¡pero el día que lo hagas vale la pena el precio 10 veces más!

Se ha debatido mucho sobre el modelo de base de datos en sí, pero también guardamos los datos necesarios en archivos .SQL.

Por ejemplo, para ser útil, su aplicación podría necesitar esto en la instalación:

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('AUD', 'Australian Dollars');

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('USD', 'US Dollars');

Tendríamos un archivo llamado currency.sqlbajo subversion. Como paso manual en el proceso de compilación, comparamos el currency.sql anterior con el último y escribimos un script de actualización.

Controlamos la versión y la fuente de todo lo que rodea nuestras bases de datos:

• DDL (crear y modificar)
• DML (datos de referencia, códigos, etc.)
• Cambios en el modelo de datos (usando ERwin o ER / Studio)
• Cambios de configuración de la base de datos (permisos, objetos de seguridad, cambios generales de configuración)

Hacemos todo esto con trabajos automatizados utilizando Change Manager y algunos scripts personalizados. Tenemos Change Manager monitoreando estos cambios y notificando cuando se realizan.

Creo que cada base de datos debería estar bajo el control de la fuente, y los desarrolladores deberían tener una manera fácil de crear su base de datos local desde cero. Inspirado por Visual Studio para profesionales de bases de datos, he creado una herramienta de código abierto que crea scripts de bases de datos MS SQL y proporciona una manera fácil de implementarlos en su motor de base de datos local. Pruebe http://dbsourcetools.codeplex.com/ . Diviértete, Nathan.

Si su base de datos es SQL Server, podríamos tener la solución que está buscando. SQL Source Control 1.0 ahora ha sido lanzado.

http://www.red-gate.com/products/SQL_Source_Control/index.htm

Esto se integra en SSMS y proporciona el pegamento entre los objetos de su base de datos y su VCS. El 'scripting out' ocurre de manera transparente (usa el motor SQL Compare bajo el capó), lo que debería hacer que su uso sea tan sencillo que no se desanime a los desarrolladores a adoptar el proceso.

Una solución alternativa de Visual Studio es ReadyRoll , que se implementa como un subtipo del Proyecto de base de datos SSDT. Esto adopta un enfoque basado en las migraciones, que se adapta mejor a los requisitos de automatización de los equipos de DevOps.

Control de origen el esquema de la base de datos mediante la secuencia de comandos de todos los objetos (definiciones de tabla, índices, procedimientos almacenados, etc.). Pero, en cuanto a los datos en sí, simplemente confíe en las copias de seguridad periódicas. Esto garantiza que todos los cambios estructurales se capturen con el historial de revisión adecuado, pero no carga la base de datos cada vez que cambian los datos.

En nuestro negocio utilizamos scripts de cambio de base de datos. Cuando se ejecuta un script, su nombre se almacena en la base de datos y no se ejecutará nuevamente, a menos que se elimine esa fila. Los scripts se nombran según la fecha, la hora y la rama del código, por lo que es posible la ejecución controlada.

Se realizan muchas pruebas antes de que los scripts se ejecuten en el entorno en vivo, por lo que las "oopsies" solo ocurren, en general, en las bases de datos de desarrollo.

Estamos en el proceso de mover todas las bases de datos al control de origen. Estamos usando sqlcompare para escribir la base de datos (una característica de edición profesional, desafortunadamente) y poner ese resultado en SVN.

El éxito de su implementación dependerá mucho de la cultura y las prácticas de su organización. La gente aquí cree en crear una base de datos por aplicación. Existe un conjunto común de bases de datos que son utilizadas por la mayoría de las aplicaciones y que causan muchas dependencias interdatabase (algunas de ellas son circulares). Poner los esquemas de la base de datos en el control de fuente ha sido notoriamente difícil debido a las dependencias interdatabase que tienen nuestros sistemas.

La mejor de las suertes para usted, cuanto antes lo pruebe, más pronto tendrá sus problemas resueltos.

He usado la herramienta dbdeploy de ThoughtWorks en http://dbdeploy.com/ . Fomenta el uso de scripts de migración. En cada versión, consolidamos los scripts de cambio en un solo archivo para facilitar la comprensión y permitir que los DBA 'bendigan' los cambios.

Esto siempre ha sido una gran molestia para mí, parece que es demasiado fácil hacer un cambio rápido en su base de datos de desarrollo, guardarlo (olvidando guardar un script de cambio), y luego está atascado. Puede deshacer lo que acaba de hacer y rehacerlo para crear el script de cambio, o escribirlo desde cero si lo desea, por supuesto, aunque eso es mucho tiempo dedicado a escribir scripts.

Una herramienta que he usado en el pasado que me ha ayudado con esto es SQL Delta. Le mostrará las diferencias entre dos bases de datos (servidor SQL / Oracle, creo) y generará todos los scripts de cambio necesarios para migrar A-> B. Otra cosa buena que hace es mostrar todas las diferencias entre el contenido de la base de datos entre la base de datos de producción (o prueba) y la base de datos de desarrollo. Dado que cada vez más aplicaciones almacenan la configuración y el estado que es crucial para su ejecución en las tablas de la base de datos, puede ser un verdadero dolor tener scripts de cambio que eliminen, agreguen y alteren las filas adecuadas. SQL Delta muestra las filas en la base de datos tal como se verían en una herramienta Diff: cambiadas, agregadas, eliminadas.

Una excelente herramienta. Aquí está el enlace: http://www.sqldelta.com/

RedGate es genial, generamos nuevas instantáneas cuando se realizan cambios en la base de datos (un pequeño archivo binario) y mantenemos ese archivo en los proyectos como un recurso. Cada vez que necesitamos actualizar la base de datos, utilizamos el kit de herramientas de RedGate para actualizar la base de datos, así como para poder crear nuevas bases de datos a partir de las vacías.

RedGate también hace instantáneas de datos, aunque personalmente no he trabajado con ellas, son igual de sólidas.

FYI Esto también fue mencionado hace unos días por Dana ... Procedimientos almacenados / esquema de base de datos en control de fuente