sql-server - tablas - sql server auditoria a bases de datos
¿Cuál es una manera fácil de implementar cambios en la base de datos utilizando SQL Server? (7)
Desarrolle su base de datos como un conjunto de parches que dependen unos de otros. Luego use una herramienta como https://github.com/LuvDaSun/sqlpatch (por mí) para crear un archivo sql para la implementación.
sqlpatch ordenará los parches en el orden correcto y se asegurará de que cada parche se ejecute exactamente una vez, incluso si el mismo script se ejecuta dos veces.
Esta estrategia se puede utilizar para la implementación de su base de datos en un entorno ci / cd. Esto hace que el despliegue sea tan fácil como empujar a una rama.
El sistema de software en el que trabajo es un sistema de facturación médica, grandes cantidades de datos y tablas de datos, y procedimientos almacenados.
Estaba leyendo el artículo " 12 Pasos para mejorar el código " y en los estados de la Prueba # 2 de Joel: ¿Puedes hacer una compilación en un solo paso?
Ahora me preguntaba, ¿significa esto una compilación de implementación (para que un cliente pueda actualizar su implementación)?
Ahora, el problema principal que estoy encontrando es cómo hacer una actualización de la base de datos en un solo paso.
En el momento actual, cuando realizamos cambios en una base de datos, todos los cambios se registran y se agregan a una secuencia de comandos de actualización de la base de datos, que recibe un número de versión adjunto cuando se crea una implementación para la compilación del cliente.
¿Hay una manera más sencilla de hacer esto? ¿Algún script o aplicación que toma un "antes y después" mira el esquema de una base de datos y crea un script de actualización como mencioné?
¿O es así como todos lo hacen, lo que me resultaría difícil de creer, pero plausible?
Un sistema automatizado reduciría los errores y aceleraría considerablemente los tiempos de desarrollo de la implementación, y me interesaría saber cómo hacerlo.
Echa un vistazo a esta entrada de blog. He usado este tipo de script de actualización única de cualquier versión de base de datos en un par de proyectos y funciona bastante bien.
http://blogs.msdn.com/danhardan/archive/2007/03/30/database-change-scripts-mambo-style.aspx
Es posible que deba ajustar un poco el flujo de trabajo para que se ajuste a su flujo de trabajo y / o actualizar el archivo .sql de la plantilla, pero en general, la idea me parece un enfoque bastante sólido para las implementaciones de bases de datos.
EDITAR: Sólo para explicar cómo he usado esta técnica. Básicamente, todos mis scripts de revisión de base de datos se ponen en el control de código fuente. Luego, como paso de compilación posterior en el cuadro de compilación, esta herramienta Mambo se ejecuta en el directorio de scripts para rodar los scripts en un solo script incluido en una transacción para permitir la reversión si algo sale mal. Luego, el instalador es lo suficientemente inteligente como para buscar el script .sql para ejecutarse en la base de datos existente.
La razón por la que esto funciona es porque el script enrollado verifica que cada pieza que era un script individual ya se haya ejecutado en la base de datos deseada. Como resultado, solo se ejecutan los últimos scripts. Una advertencia a esto es que una vez que un script se registra en el control de origen y se implementa, no puede editarlo ya que la tabla de seguimiento ya cree que el script se ha ejecutado. Eso está bien para los proyectos en los que he trabajado porque simplemente agregamos otro script a la carpeta de scripts.
Con suerte estoy explicando el proceso lo suficientemente bien como para entenderlo. Realmente no es tan complejo y puede ser muy útil si el enfoque es aplicable a su proyecto.
Hay aplicaciones que sincronizan bases de datos, pero creo que es mejor que hagas lo que estás haciendo. Escribir un script para actualizar una base de datos le brinda la capacidad de manejar errores y ejecutar transacciones. Esto se considera la mejor práctica.
Hay varios niveles de complejidad que puedes atravesar:
Si tiene scripts de actualización que crea manualmente y solo está buscando una manera de aplicarlos fácilmente a varios servidores, consulte el SSW SQL Deploy by SSW Consulting. Puede manejar ese escenario muy bien
Si tiendes a hacer más de un enfoque de diferencia de base de datos, entonces la Comparación de SQL de Red Gate (ya mencionada) y el Empaquetador de SQL hacen un gran combo. Puede diferenciar la base de datos entre lo antiguo y lo nuevo y luego aplicar los cambios en un paquete agradable, como un proyecto EXE o C #
Si desea un enfoque real, de extremo a extremo, bien pensado (con un poco de curva de aprendizaje), consulte el enfoque DBGhost de Innovartis . Es una metodología / técnica completa sobre cómo manejar el desarrollo de bases de datos y las actualizaciones incrementales. Es muy poderoso y parece muy prometedor, pero es un enfoque de todo o nada: o lo compra y lo usa de extremo a extremo, o no lo hace
¡Espero que esto ayude un poco!
Los propios Microsoft introdujeron las aplicaciones de nivel de datos en SQL 2012 como una opción gratuita para implementar y actualizar bases de datos.
Yo uso y me gusta esta herramienta, incluso para implementaciones de producción.
Responda a la primera pregunta de "Ahora me estaba preguntando, ¿esto significa compilación de implementación (para que un cliente pueda actualizar su implementación)?"
Creo que el Joel Test # 2 no es para movimientos de despliegue sino para integración continua durante el desarrollo.
En cuanto a los cambios en la base de datos en prod, todos deben hacerse a través de un script como parte de una implementación de transacción o después de que se haya realizado una copia de seguridad de la base de datos. Siempre desea poder navegar hacia atrás si algo falla en el lanzamiento.
redgate tiene una herramienta de comparación de SQL para comparar bases de datos y generar un script para sincronizar. Solíamos usarlo, pero más recientemente cambiamos a scripts manuales utilizando el mismo proceso que usted describe. El uso de scripts manuales y de grano fino con un número de versión único ha funcionado bien.
Tenemos nuestros scripts de actualización integrados en las pruebas unitarias para que se prueben junto con el código como parte de la integración continua. Creo que esta es una parte importante para "hacer una compilación en un solo paso".