He pensado y leído mucho sobre este tema. Este es un tema amplio de control de configuración y estrategia de gestión de cambios. CMMI tiene un dominio en este tema. Incluso en empresas que tienen una acreditación de CMMI 3-5, a veces no controlan la versión de sus bases de datos.
Esta pregunta debe responderse teniendo en cuenta las siguientes limitaciones .
- Tienes un guardián y cada DDL es ejecutado por este guardián.
- Otras personas tienen la capacidad de ejecutar sentencias DDL.
- Solo necesita registrar qué cambios se han realizado, pero no necesita comparar grandes diferencias.
- El diseño de su base de datos se realiza mediante una herramienta externa y luego se publica en la base de datos. Esta herramienta externa puede ser scripts DDL incluso en control de código fuente. Pero el punto clave es que controle esto y luego publique en la base de datos.
- No necesita conocer los cambios instantáneos, sino de vez en cuando: es decir, cada hora, todos los días.
- Tiene una estructura de servidor definida: Desarrollo, Prueba, Producción. Y una buena estrategia de prueba.
respuesta 1
- si 1, 4,6 es verdadero, entonces puede usar un control de fuente externo. Por ejemplo
- Embercadero tiene una herramienta de gestión de cambio de base de datos ( http://www.embarcadero.com/products/db-change-manager-xe ). Que tiene la capacidad de aplicar ingeniería inversa a una base de datos (Oracle) y ponerla en su control de origen. Luego, cualquier número de desarrolladores, dba puede alcanzar este esquema y realizar cambios en él.
- Oracle SQL Designer es similar a este enfoque.
- Poner las secuencias de comandos de la tabla para el control de origen (svn, mercurial, etc.) y mantenerlas también lo mismo.
- http://www.liquibase.org es un enfoque automatizado de arriba.
- Escribí el generador de código que generaba declaraciones DAL (Capa de acceso a datos), DDL (Crear tabla). Les pusimos control de fuente y lo mantuvimos allí. Creo que una solución dedicada como liquibase puede funcionar mejor.
Este enfoque funciona bien si tiene 6. Usted pone instrucciones DDL, que también es un código, en el control de origen y lo mantiene. Nadie cambiará los servidores de prueba y producción sin la debida consideración.
Las desventajas son si realiza algún cambio en los servidores de producción o de prueba por cualquier motivo, una corrección rápida de errores, cambio de clave principal, etc. También debe transferir esos cambios al servidor de desarrollo. Dado que en realidad el servidor de desarrollo es su VERDAD EN TIERRA. No al revés.
Este es un enfoque muy orientado al desarrollador. Pero cuando desarrolla un nuevo módulo por primera vez, funciona bastante bien.
Respuesta 2
: si 1 y 6 son verdaderos:
Un enfoque similar a la respuesta 1 es mantener un servidor de desarrollo. Todo el mundo lo usa, lo cambia. Que cuando llega el momento de actualizar. Utiliza una herramienta de comparación de bases de datos. Consíguelos como scripts, póngalos bajo control de origen.
- Red Gate Schema Compare supports Oracle
- Embercadero has similar tool
- https://github.com/carbonfive/db-migration
- http://www.sumsoftsolutions.com/svco/ (I have not used this product but I believe it belongs to this category.)
- Rails Active Migration (http://www.oracle.com/technetwork/articles/kern-rails-migrations-100756.html)
La diferencia entre la Respuesta 1 y la Respuesta 2 es que, en la respuesta 1, recopila declaraciones DDL para toda la base de datos y las almacena. En la respuesta 2, debe almacenar cada versión de cambio.
- comienzo
- V1
- V2
- V3
- ...
Si coloca una columna en una tabla y luego decide eliminarla. Sus scripts mostrarán esto en la respuesta2 mientras que en la respuesta1 solo verá la última versión. Y necesitas comparar V2 y V1 para ver las diferencias. Personalmente, me gusta la respuesta 1 mejor, ya que puedo comparar fácilmente Start y V3, V1 y V3. En la respuesta2, necesito buscar todos los cambios. También en la respuesta 2, el script en el control de la fuente tiende a ser un script complejo y de gran explosión. Difícil de encontrar información.
Respuesta 3
Si 3 es verdadero. Tenga en cuenta que en esta situación no tiene la restricción 6, es decir: no tiene servidores de Desarrollo, Prueba, Producto. Solo servidor de producción. Puede usar los desencadenadores DDL para registrar qué cambios se han realizado. Esto se usa principalmente para disuadir a las personas de abusar de sus subvenciones DDL. Si se produce algún problema, puede encontrar responsable. Para que esto funcione, cada persona debe conectarse con su cuenta de usuario y la cuenta de la Aplicación no debe tener ninguna subvención DDL. Dado que cada desarrollador conoce la cuenta de la aplicación y puede usarla.
Respuesta 4
Si tiene 3 y 5. Tenga en cuenta que en esta situación no tiene la restricción 6, es decir: no tiene servidores de Desarrollo, Prueba, Producto. Solo servidor de producción. En lugar de disparador para almacenar cambios. Utiliza una herramienta externa para buscar cambios y almacenar scripts DDL en el control de origen.
Si esta herramienta tiene la capacidad de registrar quién ha realizado cambios, sería útil. Tenga en cuenta que en esta solución pierde DDL extra que se realizan a intervalos.