Base de datos del plan de control de versiones: caliente o no?

Question

En base a la lectura de toda la web, desbordamiento de pila, y en su mayoría estos artículos sobre db de versiones que estaban vinculados a partir de terror de codificación, he hecho una puñalada en escribir un plan de control de versiones la base de datos de una página web php mysql de 8 años.

Database Version Control plan
- Create a db as the "Master Database"
- Create a table db_version (id, script_name, version_number, author, comment, date_ran)   
- Create baseline script for schema+core data that creates this db from scratch, run this on Master Db
- Create a "test data" script to load any db with working data
- Modifications to the master db are ONLY to be made through the db versioning process
- Ensure everyone developing against the Master Db has a local db created by the baseline script
- Procedures for commiting and updating from the Master Db
    - Master Db Commit
        - Perform a schema diff between your local db and the master db
        - Perform a data diff on core data between your local db and master db
        - If there are changes in either or both cases, combine these changes into an update script
        - Collect the data to be added to a new row in db_version table, and add an insert for this into the script
            - new version number = latest master db version number +1
            - author
            - comment
        - The script must be named as changeScript_V.sql where V is the latest master db version +1
        - Run the script against the master db
        - If the script executed succesfully, add it to the svn repository
        - Add the new db_version record to your local db_version table      
    - Update from Master Db
        - Update your local svn checkout to have all the latest change scripts available
        - compares your local db_version table to the master db_version table to determine which change scripts to run
        - Run the required change scripts in order against your local db, which will also update your local db_version table

Mi primera pregunta es: ¿este sonido correcto?
Mi segunda pregunta es, el proceso de confirmación parece un poco complicado de hacer más de una vez al día. ¿Hay una manera de automatizar de manera fiable? O debería ser no cometer base de datos cambia a menudo suficiente para que se importa?

Answer 1

En cuanto a sus propuestas, que no parece ser algo que es factible ni práctico. Yo estaba trabajando en una empresa donde se utilizó más de 1k tablas por base de datos (sistema muy complejo), y todo funcionaba bien como esto:

• Haga que una persona a cargo de la DB (permite llamarlo DBPerson) - cada cambio de guión / db tiene que pasar a través de él. Esto evitará cambios innecesarios, y algunos 'miradores' de los temas (por ejemplo, si alguien se mueve un índice para un mejor desempeño de su consulta, hi podría destruir otras personas de trabajo, tal vez alguien va a crear una tabla que es completamente redundante e innecesaria , etc ...). Esto mantendrá db limpia y eficiente. Incluso si parece que esto es demasiado trabajo para un individuo (o su delegado), en realidad no lo es -. El PP por lo general no suele cambiar
• Cada guión tiene que pasar a través de la validación DBPerson
• Cuando el guión es aprobada, el DBPerson asigna un número y lo pone en la 'actualización' carpeta / SVN (...), con numeración adecuado (como usted sugiere, números incrementales por ejemplo).
• A continuación, si tiene alguna integración continua en su lugar, el guión es recogido y actualizaciones de la base de datos (si usted no tiene la integración continua, hacerlo de forma manual).
• No almacene toda la escritura de base de datos, con todos los datos de secuencia de comandos. Almacenar la base de datos real en su lugar. Si tiene ramas de la solución - que cada rama con su propia base de datos, o que siempre puede tener scripts de actualización divididas para cada una de las ramas por lo que podría deshacer / enviarla a otra rama. Pero, realmente recomiendo tener una base de datos separada para cada rama.
• Tener una base de datos siempre con los datos por defecto (intacta) - para las necesidades de las pruebas unitarias, pruebas de regresión, etc. Cada vez que hacemos las pruebas, ellos lo hacen en la copia de esta base de datos. Usted podría incluso poner una limpieza nocturno de las bases de datos de prueba con el principal (en su caso, por supuesto).

En un entorno como este tendrá varias versiones de la base de datos:

• Los desarrolladores de bases de datos (local) - el que el tipo de desarrollo está usando para probar su trabajo. Siempre se puede copiar de Maestro o Maestro de prueba.
• Base de datos Maestro -. El que tiene todos los valores por defecto, tal vez semi-vacío, si está haciendo vuelve a desplegar a los nuevos clientes
• Master Test de base de datos - la base de datos principal llena de datos de prueba. Las secuencias de comandos que tienen RAN sobre el Master ejecutó aquí también.
• Prueba de la base de datos progreso - copiado de Master Test y se utiliza para probar -. Se sobreescribe antes de cualquier nueva prueba
• Si tiene ramas (base de datos similar con una ligera diferencia para cada uno de los clientes) que tendrá la misma que la anterior para cada rama ...

Usted seguramente tendrá que hacer modificaciones de este para que coincida con su situación, pero de todos modos creo que el mantenimiento de la versión textual del script de creación de base de datos entera está mal en términos de facilidad de mantenimiento, la fusión, la actualización, etc ...