Mantener las bases de datos de desarrollo en varios entornos sincronizados

Question

Estoy a punto de desarrollar una aplicación web integrada en VS2008. Tengo tanto una PC de escritorio (donde se hace la mayor parte del trabajo) como una computadora portátil (para la portabilidad ocasional) en la que utilizo AnkhSVN para mantener el código del proyecto sincronizado. ¿Cuál es la mejor manera de sincronizar mi base de datos de desarrollo (SQL Server Express)?

Tengo un proyecto de base de datos VS en SVN que contiene scripts de creación que vuelvo a generar cuando cambia el esquema. La idea original era recrear el DB cada vez que algo cambiaba, pero se está convirtiendo rápidamente en un dolor. Además, perdería todas las filas de muestra que ingresé para asegurarme de que los datos se muestran correctamente.

Estoy considerando poner los archivos .MDF y .LDF bajo control de fuente, pero dudo que SQL Server Express lo manejará correctamente si hago una actualización de SVN y los archivos se eliminan de debajo, reemplazados por copias más recientes . Pegar un par de grandes archivos binarios en el control de código fuente tampoco parece ser una solución elegante, incluso si se trata simplemente de una base de datos de desarrollo desechable. ¿Alguna sugerencia?

Answer 1

Además de su script CREATE de base de datos, ¿por qué no mantiene también una secuencia de datos predeterminada o de datos de muestra?

Este es un enfoque que hemos tomado para las versiones incrementales de una aplicación que hemos estado manteniendo durante más de 2 años, y funciona muy bien. Tener una secuencia de comandos de datos predeterminada también permite que los verificadores de QA puedan recrear los errores utilizando los datos que usted también posee.

También puede ser que desee echar un vistazo a una pregunta que he publicado hace algún tiempo:

Best tool for auto-generating SQL change scripts

Answer 2

Puede almacenar una copia de seguridad (archivo .bak) de su base de datos en lugar de archivos .LDF & .LDF.
Puede restaurar su base de datos fácilmente utilizando secuencia de comandos siguiente:

use master 
go 

if exists (select * from master.dbo.sysdatabases where name = 'your_db') 
begin 
    alter database your_db set SINGLE_USER with rollback IMMEDIATE 
    drop database your_db 
end 

restore database your_db 
from disk = 'path\to\your\bak\file' 
with move 'Name of dat file' to 'path\to\mdf\file', 
    move 'Name of log file' to 'path\to\ldf\file' 
go 

usted puede poner la escritura en Restore.sql archivo de texto antes mencionado y llamarlo desde archivo por lotes usando los siguientes comandos:

osql -E -i restore.sql 

De esa manera se puede crear el archivo de script para automatizar todo el proceso:

• Obtener última copia de seguridad db desde SVN repositorio o cualquier Stora adecuada ge
• Restaurar db actual utilizando el archivo bak

Answer 3

Obviamente, hay un número de maneras de abordar esto, así que voy a enumerar una serie de enlaces que deberían proporcionar una mejor base para construir. Estos son los enlaces a los que he hecho referencia en el pasado cuando trataba de hacer que otros se subieran al carro.

• Database Projects in Visual Studio .NET
• Data Schema - How Changes are to be Implemented
• Is Your Database Under Version Control?
• Get Your Database Under Version Control
• También busque Webcast de MSDN: Visual Studio 2005 Team Edition para Profesionales de Database (parte 4 de 4): esquema de origen y de control de versiones

Sin embargo, con todo esto dicho, si no lo cree t sombrero que se han comprometido lo suficiente como para poner en práctica algún tipo de control de versiones (ya sea manual o semiautomático), entonces yo recomiendo encarecidamente que echa un vistazo a los siguientes:

• Red Gate SQL Compare
• Red Gate SQL Data Compare

vaca Santo ! ¡Hable de hacer la vida más fácil! Tuve un proyecto para alejarme de mí y tuve a varias personas haciendo cambios en el esquema y tuve que mantener varios entornos sincronizados.Fue trivial señalar los productos de Red Gate en dos bases de datos y ver las diferencias y luego sincronizarlas.

Answer 4

Utilizamos un combo de, tomando copias de seguridad de entornos más altos.
Además de usar ApexSql para manejar la configuración inicial del esquema.
Recientemente se han utilizado migraciones subsónicas, como una forma codificada, controlada por código fuente, ejecutada a través de CI para obtener scripts de cambio, también existe el proyecto "tarantino" desarrollado por headspring de texas.

La mayoría de estos enfoques, especialmente este último, son seguros de usar además de la mayoría de los datos de prueba. Particularmente me gusta el último 2 automatizado porque puedo hacer un cambio, y la próxima vez que alguien se ponga al día, simplemente ejecutan el "actualizador" y se les envía al último.