¿Cómo se maneja la gestión de la configuración de las tablas de la base de datos?

Question

¿Cómo se maneja la administración de control de fuente y la implementación automatizada (administración de configuración) de las tablas de la base de datos? Trabajo en un entorno de SQL Server y es muy fácil crear secuencias de comandos y crear archivos para trabajos almacenados/triggers/functions even jobs. También es fácil manejar la creación de una nueva tabla db mediante scripts. Sin embargo, si en un momento posterior desea modificar esa tabla, no puede simplemente dejarla caer y volver a crearla con el nuevo campo por temor a perder datos. ¿Hay una manera automatizada de lidiar con este problema? ¿Scripts una tabla temporal y relleno después de actualizar la nueva tabla modificada? (podría ser difícil si hay una gran cantidad de datos)

Cualquier sugerencia sería muy apreciada.

Answer 1

Puede crear automáticamente la secuencia de comandos de creación inicial, pero las secuencias de comandos ALTER realmente deben codificarse a mano caso por caso, porque en la práctica necesita hacer cosas personalizadas en ellas.

En cualquier caso, necesitará alguna forma de crear scripts de aplicar y deshacer para cada cambio, y tener un script de instalador que los ejecute (y una reversión que los retrotraiga). Tal instalador probablemente debería recordar en qué versión está el esquema y ejecutar todas las migraciones necesarias, en el orden correcto.

Véase mi artículo aquí:

http://marksverbiage.blogspot.com/2008/07/versioning-your-schema.html

Answer 2

Varía, según cómo quiera tratar los datos existentes y cuán extensos sean los cambios de esquema, pero incluso en Management Studio, antes de realizar cambios, puede generar un script de todos los cambios.

Para una gran cantidad de datos o donde hay restricciones o claves externas, incluso las operaciones ALTER simples pueden tomar un tiempo significativo.

Answer 3

Existen herramientas disponibles que lo ayudan a desarrollar su esquema, desarrollar cambios, versionar esos cambios y lo ayudarán a comparar las diferencias entre las versiones e incluso generar el SQL para realizar los cambios de DDL. Por ejemplo, consulte Embarcadero Change Manager y otros productos ofrecidos por Embarcardero.

Answer 4

herramientas como SQL de Red puerta Compara son muy valiosos en asegurarse de que tiene un guión completo. Es posible que aún deba ajustarlo manualmente para asegurarse de que los objetos estén encriptados en el orden correcto. Asegúrese de crear scripts de desencadenantes y restricciones, etc., así como tablas. En general, querrá usar comandos alter en lugar de soltar y crear, especialmente si la tabla es grande.

Todas nuestras tablas y funciones y procesos almacenados están obligados a estar bajo control de fuente también, por lo que podemos volver a las versiones anteriores si es necesario. Además, nuestros dbas desentienden periódicamente cualquier cosa que no encuentren en Source COntrol, por lo que los desarrolladores se olvidan de hacerlo.

Por supuesto, todas las secuencias de comandos de desarrollo que se promocionan a producción deben ejecutarse primero en un QA o servidor de transición para garantizar que la secuencia de comandos se ejecutará correctamente (y sin cambios) antes de ejecutarse en prod. Además, debe tenerse en cuenta el tiempo de ejecución de prod, no desea bloquear a los usuarios, especialmente durante los períodos de mayor actividad, y el tiempo ha demostrado que la carga de scripts a producción tarde el viernes por la tarde suele ser una mala idea.

Answer 5

Ohh olvidé decirlo, asegúrese de tener un buen conjunto de copias de seguridad de la base de datos antes de cargar los cambios de esquema en la producción. Más vale prevenir que curar.

Answer 6

Tuvimos experiencias similares trabajando con Oracle DB. Establecimos procedimientos para adoptar SVN y scripts automatizados (que extraen cambios de SVN) para construir parches. Consulte http://www.scmsupport.com/scm.php?go=home.html y http://scmsupport.wordpress.com/ para obtener más información.