¿Utiliza el control de código fuente para los elementos de su base de datos? [cerrado]

¿Las propias bases de datos? No

Los scripts que los crean, incluyendo insertos de datos estáticos, procedimientos almacenados y similares; por supuesto. Son archivos de texto, están incluidos en el proyecto y se registran como todo lo demás.

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

Me encantan las migraciones de Rails ActiveRecord. Abstrae el script DML a ruby que luego puede ser fácilmente versionado en su repositorio de código fuente.

Sin embargo, con un poco de trabajo, usted podría hacer lo mismo. Cualquier cambio de DDL (ALTERAR TABLA, etc.) se puede almacenar en archivos de texto. Mantenga un sistema de numeración (o una marca de fecha) para los nombres de archivo y aplíquelos en secuencia.

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

Echa un vistazo a LiquiBase para administrar los cambios de la base de datos utilizando el control de código fuente.

Nunca debe 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 comprueba el número de versión actual de la base de datos contra el número más alto en el archivo, y actualiza la base de datos en su lugar. Así, por ejemplo, el último par de 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 hacer esto, pero ha funcionado para mí hasta ahora.

Sí. Código es código. Mi regla general es que necesito ser capaz de construir e implementar la aplicación desde cero, sin mirar a una máquina de desarrollo o producción.

La mejor práctica que he visto es crear un script de compilación para desechar y reconstruir su base de datos en un servidor provisional. A cada iteración se le dio una carpeta para los cambios en la base de datos, todos los cambios se escribieron con "Drop... Crear" 's . De esta manera, puede revertir a una versión anterior en cualquier momento apuntando la carpeta de compilación a la que desea la versión.

Creo que esto se hizo con Nant/CruiseControl.

SÍ, creo que es importante hacer una versión de su base de datos. No los datos, pero el esquema con seguridad.

En Ruby On Rails, esto es manejado por el framework con "migrations". Cada vez que altere la base de datos, cree un script que aplique los cambios y lo compruebe en el control de código fuente.

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 de escribir scripts para hacer lo mismo en otros frameworks que no admiten versiones de BD listas para usar.

Los nuevos proyectos de base de datos en Visual Studio proporcionan control de código fuente 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 coincidan con el otro.

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

+tom

Información adicional 2008-11-30

Lo he estado usando como un desarrollador para 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 para el lanzamiento. No se si faltan características que los DBA necesitan para proyectos de "tipo empresarial".

Debido a que el esquema está "triturado" en archivos sql, el control de código fuente funciona bien.

Una idea es que necesitas tener una mentalidad diferente cuando usas un proyecto de base de datos. La herramienta tiene un" proyecto de base de datos " en VS, que es solo el sql, más un base de datos local generada automáticamente que tiene el esquema y algunos otros datos de administración but pero ninguno de los datos de la aplicación, además de la base de datos de desarrollo local que se utiliza para el trabajo de desarrollo de datos de la aplicación. Rara vez eres consciente de la base de datos generada automáticamente, pero tienes que saber que está ahí para que puedas dejarla en paz :). Este db especial es claramente reconocible porque tiene un Guid en su nombre,

El Proyecto VS DB hace un buen trabajo integrando los cambios en la base de datos que otros miembros del equipo han hecho en su local proyecto / base de datos asociada. pero debe dar el paso adicional para comparar el esquema del proyecto con su esquema de base de datos de desarrollo local y aplicar los mods. Tiene sentido, pero parece incómodo al principio.

Los proyectos de base de datos son una herramienta muy poderosa. No solo generan scripts, sino que pueden aplicarlos inmediatamente. Asegúrate de no destruir tu base de datos de producción con ella. ;)

Me gustan mucho los proyectos VS DB y espero usar esta herramienta para todos mis proyectos db en el futuro.

+tom

Requerir que los equipos de desarrollo utilicen un sistema de gestión de control de código fuente de base de datos SQL no es la solución mágica que evitará que ocurran problemas. Por sí solo, el control de código fuente 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 código fuente, verificar el archivo de script SQL con el cliente y luego aplicar los cambios a la base de datos activa.

Puedo sugerir el uso de la Complemento SSMS llamado ApexSQL Source Control . Permite a los desarrolladores asignar fácilmente objetos de base de datos con el sistema de control de código 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 el control de fuentes de 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 y vaya al submenú ApexSQL Source Control en SSMS. Clic en la opción Vincular la base de datos al control de código fuente, seleccione el sistema de control de código fuente 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 código fuente que haya elegido.

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

Lo hago guardando scripts de create/update y un script que genera sampledata.

Sí, lo hacemos manteniendo nuestro SQL como parte de nuestra compilación keep mantenemos DROP.sql, CREAR.sql, USUARIOS.sql, VALORES.sql y version controlan estos, por lo que podemos volver a cualquier versión etiquetada.

También tenemos tareas ant 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.

Controlamos el código fuente de todos los objetos creados por dabase. Y solo para mantener a los desarrolladores honestos (porque puede crear objetos sin que estén en Control de Código fuente), nuestros dba buscan periódicamente cualquier cosa que no esté en control de código fuente y si encuentran algo, lo dejan caer sin preguntar si está bien.

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

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

Tengo todo lo necesario para recrear mi base de datos desde el metal desnudo, menos los datos en sí. Estoy seguro de que hay muchas maneras de hacerlo, pero todos mis scripts y cosas así se almacenan en subversion y podemos reconstruir la estructura de la base de datos y cosas así sacando todo eso de subversion y ejecutando un instalador.

Normalmente compilo un script SQL para cada cambio que hago, y otro para revertir esos cambios, y mantener esos scripts bajo control de versiones.

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

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

Utilizo SQL CREATE scripts exportados desde MySQL Workbech, luego utilizando su funcionalidad "Exportar SQL ALTER" termino con una serie de create scripts(numerados por supuesto) y los alter scripts que pueden aplicar los cambios entre ellos.

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

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

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

Puede hacer esto usando el Navegador de consultas MySQL o el cliente mysql.¡Voila! Su modelo y base de datos ahora han sido 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.

Sí, siempre. Debería poder recrear la estructura de la base de datos de producción con un conjunto útil de datos de muestra cuando sea necesario. Si no lo haces, con el tiempo los cambios menores para mantener las cosas funcionando se olvidan y un día te muerden, a lo grande. Su seguro que usted no puede pensar que necesita, pero el día que lo hace vale la pena el precio 10 veces más!

Ha habido mucha discusión sobre el modelo de base de datos en sí, pero también mantenemos los datos requeridos .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.sql bajo subversion. Como un paso manual en el proceso de construcción, comparamos la moneda anterior.sql a la última y escribir un script de actualización.

Nosotros controlamos la versión y el código fuente de todo lo que rodea nuestras bases de datos:

• DDL (crear y altera)
• DML (datos de referencia, códigos, etc.)
• Cambios en el modelo de datos (usando ERwin o ER/Studio)
• Cambios en la 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 un Administrador de cambios que supervisa estos cambios y notifica cuándo se producen Terminado.

Creo que cada base de datos debe estar bajo control de código fuente, y los desarrolladores deben 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 scripts bases de datos MS SQL, y proporciona una manera fácil de implementarlos en su motor de base de datos local. Intenta http://dbsourcetools.codeplex.com / . Diviértanse, - Nathan.

Si su base de datos es SQL Server, es posible que tengamos la solución que está buscando. SQL Source Control 1.0 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 la base de datos y su VCS. El 'scripting out' sucede de forma transparente (utiliza el motor de comparación SQL bajo el capó), lo que debería hacer que sea tan sencillo de usar que los desarrolladores no se desanimarán de 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.

Utilizo SchemaBank para controlar todas las versiones de mis cambios en el esquema de la base de datos:

• desde el día 1, importo mi volcado de esquema de base de datos en él
• comencé a cambiar mi diseño de esquema usando un navegador web (porque están basados en SaaS / cloud)
• cuando quiero actualizar mi servidor de base de datos, genero el script change (SQL) a partir de él 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 así que que siempre puedo rastrear cuando lo necesito.

Nuestra regla de equipo es NUNCA tocar el servidor de base de datos directamente sin almacenar el trabajo de diseño primero. Pero sucede, alguien podría estar tentado a romper la regla, en aras de conveniente. Importaríamos el volcado de esquema de nuevo en schemabank y lo dejaríamos hacer la diferencia y golpear a alguien si se encuentra una discrepancia. Aunque podríamos generar los scripts alter a partir de él para sincronizar nuestro diseño de bases de datos y esquemas, 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 esquemas bastante ordenada basada en la web con control de versiones y administración de cambios.

I source control el esquema de la base de datos mediante secuencias 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 copias de seguridad regulares. Esto asegura que todos los cambios estructurales se capturan con el historial de revisiones adecuado, pero no sobrecarga la base de datos cada vez que los datos cambian.

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 volverá a ejecutar, a menos que se elimine esa fila. Los scripts se nombran en función de la fecha, la hora y la rama de código, por lo que es posible la ejecución controlada.

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

Estamos en el proceso de mover todas las bases de datos al control de código fuente. Estamos usando sqlcompare para crear scripts en la base de datos (una función 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. Hay un conjunto común de bases de datos que son utilizados por la mayoría de las aplicaciones, así causando una gran cantidad de interdatabase dependencias (algunas de ellas son circulares). Poner los esquemas de la base de datos en control de código 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, antes tendrá sus problemas resueltos.

He utilizado la herramienta dbdeploy de ThoughtWorks en http://dbdeploy.com / . Fomenta el uso de scripts de migración. 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í también - parece que es demasiado fácil hacer un cambio rápido en su base de datos de desarrollo, guardarlo (olvidando guardar un script de cambios), y luego estás atascado. Podrías deshacer lo que acabas de hacer y rehacerlo para crear el script de cambios, o escribirlo desde cero si quieres, por supuesto, también, aunque eso es mucho tiempo dedicado a escribir scripts.

Una herramienta que he utilizado en el pasado que ha ayudado con esto es SQL Delta. Lo hará mostrar las diferencias entre dos bases de datos (SQL server/Oracle, creo) y generar todos los scripts de cambio necesarios para migrar A->B. Otra cosa agradable 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 tablas de 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 de la base de datos tal como se verían en una herramienta de diferencias: cambiadas, agregadas, eliminadas.

Una herramienta excelente. 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, además de poder crear nuevas bases de datos a partir de las vacías.

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

Para tu información esto también fue mencionado hace unos días por Dana ... Procedimientos almacenados / esquema DB en el control de código fuente