una paso para pagina ejemplo datos crear consola conectar con como codigo database svn version-control

database - paso - crear base de datos en mysql consola



Cuáles son las mejores prácticas para las secuencias de comandos de bases de datos bajo control de código (11)

Actualmente estamos revisando cómo almacenamos nuestros scripts de base de datos (tablas, procesos, funciones, vistas, arreglos de datos) en Subversion y me preguntaba si hay algún consenso sobre cuál es el mejor enfoque.

Algunos de los factores que deberíamos considerar incluyen:

  • ¿Deberíamos registrar las secuencias de comandos ''Crear'' o registrar los cambios incrementales con las secuencias de comandos ''Alter''?
  • ¿Cómo hacemos un seguimiento del estado de la base de datos para una versión determinada?
  • Debería ser fácil construir una base de datos desde cero para cualquier versión de lanzamiento dada
  • Debe existir una tabla en la base de datos que liste los scripts que se han ejecutado en su contra, o la versión de la base de datos, etc.

Obviamente es una pregunta bastante abierta, por lo que estoy ansioso por escuchar lo que la experiencia de las personas les ha enseñado.

Hay un artículo interesante en este enlace: http://www.codinghorror.com/blog/archives/001050.html

Defiende una secuencia de comandos ''crear'' de línea de base seguida de la comprobación de scripts ''alter'' y mantener una tabla de versiones en la base de datos.

Después de algunas iteraciones, el enfoque que tomamos fue más o menos así:

Un archivo por tabla y por procedimiento almacenado. También separe los archivos para otras cosas como configurar usuarios de la base de datos, rellenar tablas de búsqueda con sus datos.

El archivo para una tabla comienza con el comando CREAR y una sucesión de comandos ALTER agregados a medida que el esquema evoluciona. Cada uno de estos comandos está entre corchetes en las pruebas de si la tabla o columna ya existe. Esto significa que cada script se puede ejecutar en una base de datos actualizada y no cambiará nada. También significa que para cualquier base de datos anterior, el script lo actualiza al último esquema. Y para una base de datos vacía, el script CREATE crea la tabla y todos los scripts ALTER son omitidos.

También tenemos un programa (escrito en Python) que escanea el directorio lleno de scripts y los ensambla en un gran script. Analiza el SQL lo suficiente como para deducir las dependencias entre las tablas (basadas en referencias de clave externa) y ordenarlas de forma adecuada. El resultado es una secuencia de comandos SQL monstruosa que hace que la base de datos cumpla con las especificaciones de una vez. El programa de ensamblaje de scripts también calcula el hash MD5 de los archivos de entrada y lo usa para actualizar un número de versión que está escrito en una tabla especial en el último script de la lista.

Al no tener accidentes, el resultado es que el script de la base de datos para una versión de entrega del código fuente crea el esquema con el que este código fue diseñado para interoperar. También significa que hay un único script SQL (algo grande) para entregar al cliente para construir nuevas bases de datos o actualizar las existentes. (Esto fue importante en este caso porque habría muchas instancias de la base de datos, una para cada uno de sus clientes).

La opción de crear script:

Use crear scripts que le generarán la última versión de la base de datos desde cero, que está vacía, excepto los datos de búsqueda predeterminados.

Use técnicas de control de versiones estándar para almacenar, ramificar, etiquetar versiones y ver historias de sus objetos.

Al actualizar una base de datos en vivo (donde no desea perder datos), cree una segunda copia en blanco de la base de datos en la nueva versión y use una herramienta como el texto del enlace de la puerta roja.

Pros: los cambios en los archivos se rastrean en una forma estándar de código fuente

Contras: Confianza en el uso manual de una herramienta de terceros para realizar actualizaciones reales (poca / poca automatización)

La opción de script de actualización

Almacene cada cambio en la base de datos como un script SQL separado. Almacene cada grupo de cambios en una carpeta numerada. Use una secuencia de comandos para aplicar cambios a una carpeta a la vez y registrar en la base de datos qué carpetas se han aplicado.

Pros: ruta de actualización totalmente automatizada y comprobable

Contras: Difícil de ver el historial completo de cada elemento individual Tiene que crear una nueva base de datos desde cero, pasando por todas las versiones

Nuestra compañía los revisa simplemente porque alguien decidió ponerlo en algún documento de SOX que nosotros hagamos. No tiene ningún sentido para mí, excepto posible como documento de referencia. No veo la hora en que los saquemos y tratemos de usarlos de nuevo, y si lo hiciéramos, tendríamos que saber cuál corrió primero y cuál para ejecutar después de eso. Copia de seguridad de la base de datos es mucho más importante que mantener los scripts Alter.

Puede obtener algunos consejos al leer cómo se hace esto con las migraciones de Ruby On Rails . La mejor manera de entender esto es probarlo usted mismo y luego inspeccionar la base de datos manualmente.

Respuestas a cada uno de tus factores:

  • Almacenar scripts CREATE. Si desea ejecutar la versión xyz, sería bueno simplemente ejecutar su script de creación para configurar la base de datos de inmediato. También puede agregar scripts ALTER para pasar de la versión anterior a la siguiente (por ej., Confirma la versión 3 que contiene una secuencia de comandos CREATE de la versión 3 y una secuencia de comandos alter 2-2).
  • Ver la solución de migración de Rails. Básicamente mantienen el número de versión de la tabla en la base de datos, para que siempre lo sepas.
  • Use los scripts CREATE.
  • El uso de números de versión probablemente sea la solución más genérica: los nombres y rutas de los scripts pueden cambiar con el tiempo.

¡Mis dos centavos!

Tiendo a verificar el script de creación inicial. Luego tengo una tabla DbVersion en mi base de datos y mi código usa eso para actualizar la base de datos en la conexión inicial si es necesario. Por ejemplo, si mi base de datos está en la versión 1 y mi código está en la versión 3, mi código aplicará las sentencias ALTER para llevarlo a la versión 2, luego a la versión 3. Utilizo una declaración simple de conmutación fallida para esto.

Esto tiene la ventaja de que cuando implemente una nueva versión de su aplicación, actualizará automáticamente las viejas bases de datos y nunca tendrá que preocuparse porque la base de datos no esté sincronizada con el software. También mantiene un historial de cambios muy visible.

Esta no es una buena idea para todo el software, pero se pueden aplicar variaciones.

para cada lanzamiento necesitamos dar un archivo update.sql que contenga todos los nuevos scripts de tabla, declaraciones de modificación, paquetes nuevos / modificados, roles, etc. Este archivo se usa para actualizar la base de datos de 1 versión a 2.

Lo que sea que incluyamos en el archivo update.sql de arriba, todas estas afirmaciones deben ir a los respectivos archivos individuales. Al igual que la sentencia alter debe ir a la tabla como una nueva columna (la secuencia de comandos de la tabla debe modificarse no se agrega la declaración Alter después de crear la secuencia de comandos de la tabla en el archivo) de la misma forma que las nuevas tablas, roles, etc.

Entonces, si el usuario desea actualizar, usará el primer archivo update.sql para actualizar. Si quiere construir desde scrach, usará build.sql, que ya tiene todas las declaraciones anteriores, hace que la base de datos esté sincronizada.

sriRamulu [email protected]

Creamos una rama en Subversion y todos los cambios de la base de datos para la próxima versión están programados y registrados. Todos los scripts son repetibles, por lo que puede ejecutarlos varias veces sin error.

También vinculamos las secuencias de comandos de cambios para emitir elementos o identificadores de errores para que podamos retener un conjunto de cambios si es necesario. Luego tenemos un proceso de compilación automatizado que analiza los elementos de problema que estamos lanzando y extrae los scripts de cambio de Subversion y crea un solo archivo de script SQL con todos los cambios ordenados de manera apropiada.

Este archivo único se utiliza para promover los cambios en los entornos de prueba, control de calidad y producción. El proceso de compilación automatizada también crea entradas de la base de datos que documentan la versión (rama más ID de compilación). Creemos que este es el mejor enfoque con los desarrolladores de empresas. Más detalles sobre cómo hacemos esto se pueden encontrar AQUÍ