SQL

Question

El fondo

Mi grupo tiene bases de datos del servidor 4 de SQL:

• Producción
• UAT
• prueba
• Dev

Trabajo en el entorno de desarrollo. Cuando llega el momento de promocionar los objetos en los que he estado trabajando (tablas, vistas, funciones, procesos almacenados) hago una solicitud a mi gerente, quien promueve la prueba. Después de las pruebas, envía una solicitud a un administrador que promueve a UAT. Después de una prueba de usuario exitosa, el mismo administrador promueve la producción.

El problema

Todo el proceso es incómodo para algunas razones.

1. Cada persona debe rastrear manualmente sus cambios. Si actualizo, agrego, elimino cualquier objeto que necesite para rastrearlos para que mi solicitud de promoción contenga todo lo que he hecho. En teoría, si me pierdo algo de prueba o UAT debería atraparlo, pero esto no es seguro y es una pérdida de tiempo del probador, de todos modos.
2. Muchos de los cambios que hago son iterativos y se realizan en una GUI, lo que significa que no hay registro de los cambios que hice, solo el resultado final (al menos hasta donde yo sé).
3. Estamos en las primeras etapas de construir un data mart, por lo que la mayoría de los cambios realizados, al menos en cuanto a conteo, son cosas menores: cambiar el tipo de datos para una columna, alterar los nombres de las tablas como cristalizamos lo que van a ser usados ​​para, ajustar las funciones y procedimientos almacenados, etc.

La pregunta

gente ha estado haciendo este tipo de trabajo durante décadas, así que imagino que tienen que ser una forma mucho mejor de administrar el proceso. Lo que me gustaría es si pudiera ejecutar un diff entre dos bases de datos para ver cómo la estructura era diferente, usar ese diff para generar un script de cambio, usar ese script de cambio como mi solicitud de promoción. es posible? Si no, ¿hay otras formas de organizar este proceso?

Para el registro, somos una tienda 100% de Microsoft, acaba de actualizar todo a SQL Server 2008, por lo que cualquier herramienta disponible en ese paquete sería juego limpio.

---

Debo aclarar que no necesariamente estoy buscando herramientas de diff. Si esa es la mejor manera de sincronizar nuestros entornos, está bien, pero si hay una mejor manera de hacerlo.

Un ejemplo de lo que realmente quiero hacer son las migraciones en Ruby on Rails. Sintaxis simple muerta, todos los cambios están bien documentados automáticamente y de forma predeterminada, determinar qué migraciones deben ejecutarse es casi trivialmente fácil. Me encantaría que hubiera algo similar a esto para SQL Server.

Mi solución ideal es 1) fácil y 2) difícil de estropear. Las migraciones de Rails son ambas; todo lo que he hecho hasta ahora en SQL Server es ninguno de los dos.

Answer 1

Version Control and your Database

La raíz de todo el mal las cosas es hacer cambios en la interfaz de usuario. SSMS es una herramienta DBA, no una herramienta de desarrollador. Los desarrolladores deben usar los scripts para realizar cualquier tipo de cambios en el modelo/esquema de la base de datos. El control de versiones de sus metadatos y la secuencia de comandos de actualización de cada versión N a la versión N + 1 es solo que ha demostrado que funciona de manera confiable. Es la solución que SQL Server despliega para realizar un seguimiento de los cambios de metadatos (cambios de db de recursos).

Las herramientas de comparación como SQL Compare o vsdbcmd y los archivos .dbschema de los proyectos de la base de datos VS son solo los últimos recursos para las tiendas que no tienen un enfoque de versiones adecuado. Trabajan en escenarios simples, pero veo que todos fallan espectacularmente en despliegues serios. Uno simplemente no confiar en una herramienta para hacer un cambio de mesa + 5 TB si las herramientas trata de copia los datos ...

Answer 2

RedGate vende SQL Compare, una excelente herramienta para generar scripts de cambio.

Visual Studio también tiene ediciones que permiten comparar bases de datos. Esto anteriormente se llamaba Database Edition.

Donde trabajo, abolimos la separación Dev/Test/UAT/Prod hace mucho tiempo a favor de un very quick release cycle. Si ponemos algo roto en la producción, lo arreglaremos rápidamente. Nuestros clientes son ciertamente más felices, pero en el caso de evitar riesgos corporativos, puede ser difícil de vender.

Answer 3

Hay varias herramientas disponibles para usted. Uno es de Red-Gate llamado SQL Compare. Increíble y altamente recomendado. SQL Compare le permitirá hacer un diff en esquemas entre dos bases de datos e incluso crear los scripts de cambio sql para usted.

Tenga en cuenta que también han estado trabajando en un producto de control de código fuente SQL Server por un tiempo.

Otro (si usted es una tienda de estudio visual) es el esquema y las características de comparación de datos que es parte de Visual Studio (no estoy seguro de qué versiones).

Answer 4

Dentro de nuestro equipo, nos ocupamos de los cambios de base de datos como este:

• Nosotros (re) generar una secuencia de comandosque crea la base de datos completa y comprobar en el control de versiones, junto con los otros cambios. Tenemos 4 archivos: tablas, funciones y vistas definidas por el usuario, procedimientos almacenados y permisos. Esto es completamente automático: solo se necesita un doble clic para generar el script.
• Si un desarrollador tiene que realizar cambios en la base de datos, lo hace en su db local.
• Para cada cambio, creamos guiones de actualización. Esos son fáciles de crear: el desarrollador regenera el script db de su db local. Todos los cambios ahora son fáciles de identificar gracias al control de versiones. La mayoría de los cambios (nuevas tablas, vistas nuevas, etc.) pueden simplemente copiarse al script de actualización, otros cambios (agregar columnas, por ejemplo) deben crearse manualmente.
• La secuencia de comandos de actualización se ha probado en nuestra base de datos de desarrollo común, o volviendo la copia de seguridad local a la última copia de seguridad creada antes de comenzar a cambiar la base de datos. Si pasa, es hora de comprometer los cambios.
• Las secuencias de comandos de actualización siguen una convención de nomenclatura para que todos sepan en qué orden ejecutarlas.

Esto funciona bastante bien para nosotros, pero aún necesita cierta coordinación si varios desarrolladores modifican en gran medida las mismas tablas y vistas. Esto no sucede a menudo sin embargo.

Los puntos importantes son:

• estructura de base de datos sólo modificada por los scripts, a excepción de db del promotor local. Esto es importante.
• scripts SQL crean versiones de de control de código fuente - el PP se puede crear como lo fue en algún momento en el pasado la base de datos
• copias de seguridad se crean regularmente - al menos antes de hacer cambios a la db
• cambios en el db se pueden hacer rápidamente, porque los scripts para esos cambios se crean con relativa facilidad.

Sin embargo, si tiene muchas ramas de desarrollo de larga duración para sus proyectos, es posible que esto no funcione.

No es, de lejos, una solución perfecta, y se deben tomar algunas precauciones especiales. Por ejemplo, si hay actualizaciones que pueden fallar dependiendo de los datos presentes en una base de datos, la actualización debe probarse en una copia de la base de datos de producción.

A diferencia de las migraciones de rieles, no creamos scripts para invertir los cambios de una actualización. Pero esto no siempre es posible de todos modos, al menos con respecto a los datos (el contenido de una columna eliminada se pierde incluso si recrea la columna).

Answer 5

De acuerdo en que SQL Compare es una herramienta increíble.

Sin embargo, no realizamos ningún cambio en la estructura de la base de datos ni en los objetos que no tienen secuencia de comandos ni se guardan en el control de origen como todos los demás códigos. Entonces sabrá exactamente qué pertenece a la versión que está promocionando porque tiene los scripts para esa versión en particular.

De todos modos, es una mala idea hacer cambios estructurales a través de la GUI. Si tiene muchos datos, es mucho más lento que usar Alter Table al menos en SQL Server. Solo desea usar scripts probados para realizar cambios en prod.

Answer 6

Otra herramienta "Diferencias" para las bases de datos:

http://www.xsqlsoftware.com/Product/Sql_Data_Compare.aspx

Answer 7

I de acuerdo con los comentarios hechos por marapet, donde cada cambio debe ser escrito.
El problema que puede estar experimentando, sin embargo, es crear, probar y rastrear estos scripts.
Eche un vistazo al motor de parcheo utilizado en DBSourceTools.
http://dbsourcetools.codeplex.com

Ha sido diseñado específicamente para ayudar a los desarrolladores a obtener bases de datos de SQL Server bajo control de código fuente.

Esta herramienta le permitirá basar su base de datos en un punto específico y crear una versión con nombre (v1).
A continuación, cree un destino de despliegue e incremente la versión nombrada a v2.
Agregue scripts de parche al directorio Patches para cualquier cambio en el esquema o los datos.
Finalmente, verifique la base de datos y todos los parches en el control del código fuente, para distribuirlos con los desarrolladores.

Lo que esto le ofrece es un proceso repetible para probar todos los parches que se aplicarán de v1 a v2.
DBSourceTools también tiene una funcionalidad para ayudarlo a crear estos scripts, es decir, comparar esquemas o herramientas de datos de scripts.

Una vez que haya terminado, simplemente envíe todos los archivos en el directorio de parches a su DBA para actualizar de v1 a v2.

Diviértete.

Answer 8

1. versión de la base de datos Tenga en una tabla de versiones
2. Mantener nombre de archivo de secuencia de comandos que se aplicó con éxito
3. Mantener suma md5 de cada secuencia de comandos SQL que se ha aplicado. Debe ignorar espacios cuando calcule md5 sum. Debe ser efectivo.
4. Mantener información sobre quien aplicó un guión Mantener información sobre cuando se aplicó un guión
5. base de datos debe ser verificada en el inicio de la aplicación
6. Nueva secuencia de comandos SQL se debe aplicar automáticamente
7. Si la suma MD5 de un guión que ya se aplicó se cambia, se debe generar un error (en modo de producción)
8. Cuando se ha liberado el script, no se debe cambiar. Debe ser inmutable en un entorno de producción.
9. La secuencia de comandos debe escribirse de manera que se pueda aplicar a diferentes tipos de base de datos (ver liquibase)
10. Dado que la mayoría de las sentencias ddl se autoinfirman en la mayoría de las bases de datos, es mejor tener una única instrucción ddl Secuencia de comandos SQL
11. DDL instrucción sql debe ejecutarse de una manera, por lo que se puede ejecutar varias veces sin errores. Realmente ayuda en un modo de desarrollo, cuando puede editar secuencias de comandos varias veces. Por ejemplo, cree una nueva tabla, solo si no existe, o incluso deje caer la tabla antes de crear una nueva. Le ayudará en un modo de desarrollo, con un script que no se ha publicado, cámbielo, borre md5 sum para este script, vuelva a ejecutarlo.
12. Cada secuencia de comandos sql debe ejecutarse en su propia transacción.
13. Los desencadenantes/procedimientos deben soltarse y crearse después de cada actualización de db .
14. secuencia de comandos SQL se mantiene en un sistema de control de versiones como SVN
15. nombre de un guión contiene la fecha en que se cometió, existente (jira) Identificación del problema, pequeña descripción
16. Evitar la adición de la funcionalidad de reversión en los scripts (Liquibase permite hacer ese). Les hace más complicado escribir y apoyar.Si utiliza exactamente una instrucción DDL por la escritura, y DML declaraciones se ejecuta dentro de una transacción , incluso a falta de una secuencia de comandos no será un gran problema para resolverlo