Control de versiones con SQL Server

Estoy comenzando un nuevo proyecto y estoy usando SVN (con Tortoise) como mi sistema de control de versiones. Me preguntaba si era posible mantener también una base de datos de SQL Server usando el mismo sistema.

Me gustaría versionar mis tablas / funciones / vistas / procs / triggers / etc. pero no mis datos, ya que todos serán datos de prueba de todos modos. No estoy realmente seguro de cómo configurar esto. He encontrado algunas opciones, pero me gustaría saber si faltaba alguna, y si tal vez hay una guía o algo por ahí que me ayude a seguir adelante.

He visto y oído hablar de Red Gate, pero estoy buscando algo gratis (o al menos de muy bajo costo). Sé que siempre podría escribir algo yo mismo, pero realmente no estoy tratando de pasar tiempo en eso.

Una cosa que encontré fue un paquete de código abierto creado llamado ScriptDB4Svn . ¿Alguien ha usado esto antes? ¿Esta bien? ¿Puede hacer las cosas que necesito que haga y es bastante sencillo configurarlo?

Técnicamente ni siquiera necesita una herramienta, puede escribir los objetos directamente y verificarlos en el control de origen. Es un poco más trabajo sin la herramienta, pero definitivamente es viable.

Por cierto: he usado la herramienta RedGate y es bastante ingeniosa y vale la pena.

Parece que tienes una configuración principalmente de Microsoft. Puede echar un vistazo a Proyectos de base de datos (anteriormente conocido como DataDude). Básicamente convierten T-SQL en un lenguaje de primera clase en Visual Studio; usted puede:

• Compile proyectos: no solo crea un script final, se asegura de que existan nombres de objetos, etc.
• Realice un análisis de código estático, por ejemplo, asegurándose de que siempre se refiera a los objetos al incluir su esquema (por ejemplo, [dbo]en la mayoría de los casos) para ese aumento de rendimiento del 30%.
• Cree scripts de diferencias haciendo que compare diferentes versiones del proyecto.
• Actualice su proyecto desde una base de datos o script (ingeniería inversa).
• Intellisense.
• No hay herramientas de diagramación.

Unifican su código y el código de su base de datos muy bien también bajo control de fuente. Si por el hombre arriba y la escritura sus objetos de bases de datos (en lugar de utilizar herramientas de Davinci en SSMS) también tierra hasta el uso de una IDE - que es agradable.

Puedes usar Rails. Rails tiene un concepto de migraciones de bases de datos que puede aplicar o revertir. En mi experiencia, esta es la mejor manera de versionar una base de datos. Verifica estos archivos de migración en SVN.

En mi proyecto actual, no estamos desarrollando la aplicación en Ruby, pero aún estamos usando Rails para administrar la base de datos. No lo haría de otra manera.

Esto se ha discutido antes en stackoverflow: /programming/2750278/sql-server-2008-create-database-script-schema-data-with-command-line

Además, este artículo externo proporciona información adicional http://www.sqlteam.com/article/scripting-database-objects-using-smo-updated junto con un código de muestra en forma de una aplicación de Windows.

Como lo que desea hacer es algo que he hecho yo mismo para MS Access, le diré lo que he hecho en caso de que le dé algunas ideas: he escrito un módulo llamado Ado2Xml que convierte el esquema y los datos de cualquier ADO -base de datos accesible a xml y viceversa. Sin embargo, solo conoce tablas y vistas; sin procedimientos almacenados, sin desencadenantes, sin nada. De todos modos, en su caso, este módulo se reemplaza por la herramienta que probablemente encontrará que hace lo que quiere con MS-SQL. Por lo tanto, cada vez que se inicia mi aplicación, compara la marca de tiempo de la base de datos con la marca de tiempo del archivo xml guardado; si el archivo xml es más reciente, destruye la base de datos e invoca Ado2Xml para volver a crearlo a partir del archivo xml. Cuando mi aplicación finaliza, hace lo contrario: invoca Ado2Xml para exportar la base de datos al archivo xml. Realmente, Los objetos ADO que extraen el esquema de la base de datos son, por alguna razón, muy lentos, lo que hace que el proceso de exportación tarde un poco. Entonces, para evitar tener que esperar cada vez que mi aplicación finalice y Visual Studio cambie del diseño de depuración al diseño de edición, justo antes de que finalice, mi aplicación inicia una aplicación externa para exportar, de modo que pueda finalizar inmediatamente.

Sí, he usado una herramienta similar (desarrollada internamente) en un proyecto anterior. Escribiría todas las tablas, vistas, sprocs, disparadores, etc. en archivos .sql individuales. Luego, teníamos un script que se ejecutaba todas las noches para "validar" que todo en nuestra base de datos de "desarrollo" se reflejaba en el control de la fuente.

Entonces, el flujo de trabajo normal es que cambiaría su código, cambiaría las tablas y los sprocs correspondientes en la base de datos de desarrollo según sea necesario, luego ejecutaría la herramienta que teníamos y actualizaría todos los archivos .sql con script. Luego verificaría todo de una vez.

El problema era que si olvidaba ejecutar la herramienta, el código "funcionaría" (y las pruebas unitarias pasarían) porque la base de datos era "correcta", pero los nuevos sprocs / tables no serían el control de origen.

Entonces, todas las noches, tenemos un script que realizó una comprobación del código fuente, luego rand la herramienta para actualizar todos los scripts. Si hubo alguna diferencia, significa que alguien olvidó revisar sus cambios y se generó una notificación por correo electrónico. Básicamente era solo una forma de asegurarnos de que no nos olvidemos de mantener actualizado el control de la fuente.

Fue un poco molesto porque dificultaba trabajar en cambios que abarcaron varios días, pero era mejor que no tener nada ...