Control de versiones con SQL Server

14

Estoy empezando un nuevo proyecto y uso SVN (con Tortoise) como mi Sistema de Control de Versiones. Me preguntaba si también era posible mantener una base de datos de SQL Server utilizando 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 muy seguro de cómo configurar esto. He encontrado algunas opciones, pero me gustaría saber si faltaba alguna y si hay alguna guía o algo para ayudarme a correr con ella.

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

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

    
pregunta yannis 10.01.2012 - 03:25

5 respuestas

2

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

BTW: He usado la herramienta RedGate y es bastante elegante y vale la pena.

    
respondido por el JohnFx 10.01.2012 - 05:17
1

Parece que tienes una configuración principalmente de Microsoft. Podría 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:

  • Compilar proyectos: no se limita a crear un script final, se asegura de que existan nombres de objetos, etc.
  • Realice análisis de código estático, por ejemplo, asegurándose de que siempre haga referencia a los objetos al incluir su esquema (por ejemplo, [dbo] en la mayoría de los casos) para obtener un aumento de rendimiento del 30%.
  • Cree scripts de diferencias al hacer 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.

También unifican su código y el código de su base de datos bajo el control de código fuente. Si man-up y escribe sus objetos de base de datos (en lugar de usar Davinci Tools en SSMS), también obtiene un IDE, lo que es bueno.

    
respondido por el Jonathan Dickinson 10.01.2012 - 09:06
0

Puedes usar Rails. Rails tiene un concepto de migraciones de base 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 seguimos usando Rails para administrar la base de datos. No lo haría de otra manera.

    
respondido por el Vinnie 10.01.2012 - 04:53
0

Esto se ha discutido anteriormente en stackoverflow: enlace

Además, este artículo externo proporciona información adicional enlace junto con una muestra código en la forma de una aplicación de Windows.

Ya que lo que quieres hacer es algo que hice solo para MS Access, te diré lo que he hecho en caso de que te dé algunas ideas: He escrito un módulo llamado Ado2Xml que convierte el esquema y los datos. de cualquier base de datos accesible a ADO a xml, y viceversa. Sin embargo, solo se sabe de tablas y vistas; Sin procedimientos almacenados, sin disparadores, sin nada. De todos modos, en su caso, este módulo es reemplazado por la herramienta que probablemente encontrará que hace lo que quiere con MS-SQL. Por lo tanto, cada vez que mi aplicación se inicia, 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 desde el archivo xml. Cuando mi aplicación termina, hace lo contrario: invoca Ado2Xml para exportar la base de datos al archivo xml. En realidad, 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. Por lo tanto, para evitar tener que esperar cada vez que finalice mi aplicación y Visual Studio para cambiar 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 realizar la exportación, para que pueda finalizar. inmediatamente.

    
respondido por el Mike Nakis 10.01.2012 - 09:25
0

Sí, he usado una herramienta similar (desarrollada internamente) en un proyecto anterior. Guionaría todas las tablas, vistas, sprocs, disparadores, etc. en archivos .sql individuales. Luego, tuvimos 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 código fuente.

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

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

Entonces, cada noche, tenemos un script que verifica el código fuente y luego ejecuta la herramienta para actualizar todos los scripts. Si hubo alguna diferencia, significa que alguien se olvidó de verificar sus cambios y se generó una notificación por correo electrónico. Básicamente, fue solo una forma de asegurarnos de que no nos olvidamos de mantener actualizado el control de la fuente.

Fue un poco molesto porque dificultó trabajar en los cambios que se realizaron en varios días, pero fue mejor que no tener nada ...

    
respondido por el Dean Harding 10.01.2012 - 04:27

Lea otras preguntas en las etiquetas