Versioning SQL Server Código DDL

Question

Me gustaría tener todos los DB código DDL bajo CVS.

Estamos utilizando Subversion para nuestro código .NET pero todo el código de la base de datos sigue sin ser versionado.

Todo lo que sabemos es cuán importante puede ser la lógica de DB. Busqué en Google pero solo encontré algunas (herramientas costosas). Creo que existe otra solución (más barata).

¿Qué enfoque recomienda seguir? ¿Qué herramientas son las más apropiadas?

SQL Server 2005, VS 2008 TS, TSVN

ACTUALIZACIÓN Nuestro escenario de codificación es que los desarrolladores no pueden acceder a la base de datos directamente PROD. Solo lo cambian las secuencias de comandos (así que esto no es un problema)

Estoy interesado principalmente en el entorno DEV donde todos los desarrolladores tienen acceso completo.
Ocurre que un desarrollador sobrescribe USP previamente cambiado por otro.
me gustaría tener la posibilidad de restaurar la versión perdido/USPs comparar las revisiones etc.

ACTUALIZACIÓN-2
Para crear script de implementación que estamos usando Rojo-Gate SQL Comparar.
Funciona perfectamente, por lo que las secuencias de comandos de implementación no son un caso.

Answer 1

Finalmente encontré esta herramienta y el enfoque extremadamente útil y muy fácil de introducir
(al menos al principio - donde hay una solución de control de versiones en el lugar):

http://www.codeproject.com/KB/database/SQLScripter.aspx

se puede ejecutar a cabo De la caja.
Para una solución final me inclinaría a GDR.

Answer 2

Si aún no lo ha leído, el artículo de Martin Fowler Evolutionary Database Design es un gran lugar para comenzar.

El artículo es difícil de resumir, pero describe cómo su equipo se ocupó del control de versiones de la base de datos en un proceso de desarrollo que cambia rápidamente. Crearon sus propias herramientas para facilitar las cosas: scripts para acercar a los usuarios al maestro actual, copiar cualquier versión del esquema para que los usuarios puedan depurar las copias de trabajo de los demás, etc.

Para una solución sólida de baja tecnología, He encontrado que es útil mantener dos tipos de secuencias de comandos DDL en el control de código fuente:

• Una versión maestra que puede crear los objetos de la base de datos desde cero.
• 'Actualizaciones de versiones' para cada iteración de desarrollo.

Son redundantes en cierta medida, pero extremadamente útiles (especialmente cuando se trata de la implementación).

Answer 3

Si está usando Visual Studio Team Suite o Visual Studio Developer Edition, tiene derecho a una copia de Visual Studio Database Professional. Esto está diseñado para hacer exactamente lo que describes, y mucho más. Lo usamos para administrar nuestro esquema de base de datos (código).

Randy

Answer 4

Si aún no lo ha mirado a la base de datos de Visual Studio Edición RDA (también denominado"Datos Dude"), que sin duda debe descargarlo y probarlo:

http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&displaylang=en

Entre otras cosas, la RDA facilitará el desarrollo del equipo por lo que es fácil para cada desarrollador para mantener su propia copia local de una base de datos, scripts de versión, crear scripts de despliegue para mover un esquema de base de datos a una nueva versión, e incluso soportar la reversión de la base de datos.

Es gratis si usa la edición del desarrollador del sistema de equipo. Echale un vistazo.

Answer 5

Usamos Subversion para todo nuestro código de base de datos también. Dado que no se permite que nada vaya a Prod a menos que esté en un guión, no parece haber ningún problema con que la gente ponga todos los guiones en subversión. Tendemos a escribir scripts alter table para cambiar las tablas con datos existentes y luego recrear toda la estructura de la tabla en caso de que necesitemos crear una nueva base de datos desde cero (a menudo tenemos la misma estructura de base de datos en varios servidores ya que algunos de nuestros clientes son muy grandes y no quieren que sus datos estén accidentalmente disponibles para la competencia y así pagar por servidores separados y, por lo tanto, pueden necesitar crear toda la base de datos nuevamente sin datos). Para objetos que no almacenan datos directamente, soltamos el objeto original y lo recreamos con una declaración de crear. Cada proyecto tiene su propio hogar en el repositorio y cada base de datos también lo hace, por lo que el script puede estar en más de un lugar para facilitar la implementación.

Pero la verdadera clave es que nadie puede cargar Prod sin una secuencia de comandos. No le damos a nuestros desarrolladores derechos directos para prod, por lo que no tienen problemas para hacer cosas en scripts en lugar de usar SSMS.

Answer 6

Esto también suena interesante:

freeware:
http://dbsourcetools.codeplex.com/
http://www.codeproject.com/KB/database/ScriptDB4Svn.aspx
http://www.codeproject.com/KB/database/SQLScripter.aspx
http://blog.boxedbits.com/archives/133

Comercial:
http://www.nobhillsoft.com/Randolph.aspx

Answer 7

Consulte si Wizardby se adecua a sus necesidades.

Answer 8

Escribí SMOscript que genera un script CREATE para cada objeto en una base de datos.

Utilice esta herramienta para generar en un directorio cubierto por CVS, y actualice su repositorio.

Answer 9

Debe utilizar Management Studio (SSMS) y colocar .sql bajo control de código fuente, posiblemente objetos de esquema separados en carpetas. Espero que esto ayude