¿Deben los archivos de base de datos (scripts, etc.) estar en control de fuente? Si es así, ¿cuál es el mejor método para mantenerlo y actualizarlo allí?

¿Existe incluso la necesidad de que los archivos de la base de datos estén en control de fuente ya que podemos ponerlo en un servidor de desarrollo donde todos puedan usarlo y hacer cambios si es necesario? Pero, entonces no podemos recuperarlo si alguien lo estropea.

¿Qué enfoque se usa mejor para las bases de datos sobre control de código fuente?

Si. Debería poder reconstruir cualquier parte de su sistema a partir del control de origen, incluida la base de datos (y también argumentaría ciertos datos estáticos).

Suponiendo que no desea tener una herramienta para hacerlo, le sugiero que desee incluir lo siguiente:

• Scripts de creación para las estructuras básicas de la tabla, incluidos esquemas, usuarios, tablas, claves, valores predeterminados, etc.
• Scripts de actualización (ya sea alterando la estructura de la tabla o migrando datos de un esquema anterior al nuevo esquema)
• Scripts de creación para procedimientos almacenados, índices, vistas, activadores (no necesita preocuparse por la actualización de estos, ya que simplemente sobrescribe lo que estaba allí con el script de creación correcto)
• Scripts de creación de datos para que el sistema funcione (un solo usuario, cualquier dato de lista de selección estática, ese tipo de cosas)

Todos los scripts deben incluir las declaraciones de caída apropiadas y deben escribirse para que puedan ejecutarse como cualquier usuario (incluidos los prefijos de esquema / propietario asociados, si corresponde).

El proceso para actualizar / etiquetar / bifurcar debe ser exactamente como el resto del código fuente: no tiene mucho sentido hacerlo si no puede asociar una versión de base de datos con una versión de aplicación.

Por cierto, cuando dices que la gente puede actualizar el servidor de prueba, espero que te refieras al servidor de desarrollo. Si los desarrolladores están actualizando el servidor de prueba sobre la marcha, entonces estás viendo un mundo de dolor cuando se trata de resolver lo que necesitas liberar.

Si.

¿Cuál es el mejor método para mantenerlo y actualizarlo allí?

Um. Escriba un script de generador de esquemas. Revísalo después de hacer cambios. Compruébalo antes de ejecutarlo.

Es difícil determinar lo que estás pidiendo.

Escribir scripts de migración de esquemas formales. Verifíquelos después de la prueba. Échales un vistazo antes de ejecutarlos.

Que mas hay

Lo que sucede es que los cambios de esquema se convierten en problemas retorcidos porque el esquema evoluciona orgánicamente a través de una serie de cambios no documentados.

Esta evolución orgánica hace que la migración del esquema sea más difícil porque no hay una fuente "autorizada" para lo que se supone que debe estar allí. Hay dos versiones de producción ligeramente diferentes, una versión provisional, una versión de control de calidad y ocho versiones de desarrollo. Todo un poco diferente.

Si hubo una única fuente autorizada, entonces la migración del esquema es solo el delta entre la última versión y esta versión.

si

Los scripts de base de datos (ddl, dml) son código. Todo el código debe estar en un sistema de control de versiones.

Migraciones

• Usar migraciones de bases de datos

Le permite usar los mismos archivos db en desarrollo, qa y lanzamientos.

• Lanzamiento a la base de datos con un número de lanzamiento

Almacene el número de versión en algún lugar para auditar, muchos lo almacenan en el propio db. Cada versión estará compuesta de migraciones que llevarán la base de datos a la versión correcta.

Hay herramientas como liquibase que están destinadas a proporcionar control de origen para bases de datos. Es engorroso mantener los scripts de cambio / actualización en su herramienta de control de fuente habitual, como lo hacen muchas empresas, y no siempre se puede volver a implementar la base de datos desde cero.

También hemos tratado de automatizar esto con herramientas de comparación de bases de datos (comparar db maestro frente a cliente) y eso ayudó, pero no puede confiar en esas herramientas al 100%, definitivamente también necesita un proceso de revisión.

si

Y además, querrás ramas .

Yo uso Git para ramas:

• para el desarrollo por función (como lo hacemos para el desarrollo regular del resto de la aplicación)

• y también para el servidor de producción porque los clientes que usan la aplicación también crean contenidos.

De esa manera, obtiene los beneficios del control de origen y la ramificación tanto para los códigos fuente como para la base de datos (y cualquier otro archivo que tenga).

Todavía no he encontrado un sistema todo en uno [para PostgreSQL], por lo que tuve que escribir funciones / scripts para reindexar correctamente al fusionar ramas (por ejemplo, cualquier índice de la rama de producción no debe modificarse porque los clientes confían en ellos mientras que Los índices + claves externas de la rama de desarrollo que se cruzan con los contenidos de producción deben reindexarse: no funcionaría para todas las aplicaciones, pero cubre todos los casos de nuestra aplicación, por lo que es lo suficientemente bueno).

Pero la idea general es que el contenido de la base de datos es una parte esencial de la aplicación, y todos los recursos deben estar en el control de origen , por lo tanto, sí, también debe usar el control de origen para la base de datos.

Para Java, nuestro equipo usa Flyway , que encontramos realmente fácil de usar y potente.

Si está trabajando en Ruby, Rails tiene migraciones, que también son una forma poderosa de tratar este problema.

Liquibase ya se ha mencionado: es una buena solución, pero me pareció más engorroso que alternativas como Flyway.

Además, el software RedGate ofrece un producto llamado SQL Source Control que está diseñado para SQL Server. No lo he usado yo mismo, pero uno de mis compañeros de trabajo dice que es genial.

Este es el problema que he visto muchas veces cuando no hay control de versiones o gestión de cambios en las bases de datos de desarrollo. El programador A realiza un cambio en una tabla, vista o proceso. El Programador B hace un cambio en lo mismo y sobrescribe lo que hizo el Programador A. O bien, DBA restaura una base de datos de producción al desarrollo y sobrescribe los cambios. He visto este tipo de cosas que causan un dolor considerable tantas veces que no es gracioso. Y esto es solo en sistemas de desarrollo. Las cosas pueden ponerse muy complicadas cuando se realiza una prueba / ensayo e incluso los servidores de producción quedan atrapados en esto.

El control de versión de la base de datos no tiene que ser el mismo que el control de versión de código normal para ser efectivo. Sin embargo, algún tipo de control de cambios y copias de seguridad del historial evitarán muchos problemas.

Piense en ello como "Control de versiones" en lugar de "Control de código fuente". Esto implica que puede ver la historia completa de ese script en particular. Si puede o no reconstruir la base de datos a su forma actual, será más una cuestión de sus prácticas con respecto a estos scripts y los marcos utilizados para crearlos.

Para nuestros proyectos PHP / MySQL, hemos estado usando una (pequeña) herramienta llamada Ladder . Está diseñado para facilitar el crecimiento orgánico de una base de datos a lo largo del tiempo. Todas las migraciones de un proyecto se almacenan en el control de revisión / fuente / versión y se rastrean junto con el código.

Admite agregar / alterar / eliminar columnas, ejecutar consultas, agregar / eliminar índices, restricciones, etc., realizará un seguimiento del estado en que se encuentra la base de datos y aplicará las migraciones faltantes. También le permite "retroceder en el tiempo" al especificar una migración en la que necesita estar. ( php ladder.php migrate 15)

Ah, y la última incorporación es la base de datos diferente. Ejecute el diff-savecomando, agregue y elimine algunas columnas de la base de datos y ejecute su diffcomando. Verá el código de migración generado automáticamente en función del estado de la base de datos.

DataGrove resuelve algunos de los problemas mencionados aquí (por jfrankcarr , por ejemplo).

Realiza un seguimiento de todos los cambios en una base de datos y le permite guardar una versión de todo el estado de la base de datos en un repositorio. Luego le permite generar múltiples copias virtuales de la misma base de datos, por lo que cada desarrollador o DBA puede tener su propia copia separada (cada copia virtual se puede generar a partir de una versión diferente). Se asegurará de que nadie anule el código / los cambios de otra persona. Cada una de las copias virtuales también se rastrea en los mismos repositorios para que todos los estados de la base de datos se puedan compartir y recrear fácilmente.

También me gustaría traer una herramienta de monitoreo que también se puede utilizar como herramienta de control de versiones de datos. La herramienta de la que estoy hablando es MONyog, en realidad es una herramienta de monitoreo de MySQL, pero con un pequeño truco podemos usarla fácilmente como versiones de datos.

Pero antes de continuar, citaré que no será aconsejable poner toda la base de datos para el control de versiones. Es realmente asesino rastrear el cambio para un conjunto particular de datos.

MONyog tiene una característica llamada CSO (Custom SQL Objects), que puede monitorear el cambio en un conjunto particular de datos. Agregar un CSO se describe aquí . Ahora en la sección de historial de monitores de MONyog puede obtener los cambios durante un período de tiempo. Lo mejor es que proporciona un informe visual en la página html. El informe se verá así