Administrar mi base de datos en Source Control

Question

Como estoy trabajando con un nuevo proyecto de base de datos (dentro de VS2008), y como nunca he desarrollado una base de datos desde cero, comencé a buscar cómo administrar una base de datos dentro del control de fuente (en este caso, Subversion).

Encontré algo de información sobre SO, incluida esta publicación: Keeping development databases in multiple environments in sync. One of the answers in particular señaló una serie de enlaces, todos los cuales tenían información buena y útil.

Estaba leyendo un series of posts de K. Scott Allen que describe cómo gestiona el cambio de la base de datos. A partir de mi lectura (y por favor, perdónenme el noobismo de mi pregunta), parece como si la base de datos nunca se registrara en un repositorio. Por el contrario, las secuencias de comandos que pueden construir la base de datos, junto con los datos de prueba (que también se rellena desde scripts) se registran en el repositorio. En última instancia, esto significa que, cuando un desarrollador prueba su aplicación, se ejecutan estos scripts, que son parte del proceso de compilación. Esto garantiza que la base de datos esté actualizada, pero también se ejecuta localmente desde la máquina de cada desarrollador.

Esto tiene sentido para mí (si de hecho lo estoy leyendo correctamente). Sin embargo, si me falta algo, agradecería una corrección u orientación adicional. Además, otra pregunta que quería hacerme ¿significa esto también que debería NO marcar en el mdf o ldf archivos que se crean desde Visual Studio?

Gracias por cualquier ayuda y visión adicional. Siempre apreciado

Answer 1

Correcto, debe comprobar las secuencias de comandos, no el archivo de la base de datos.

No me gusta construir a partir de datos de prueba a menos que los datos imiten el tamaño de los datos que la producción (o, en el caso de nuevas bases de datos, se supone que tienen). ¿Por qué? porque escribir código en una tabla con 100 registros no le dice si se ejecutará de manera oportuna cuando tenga 10,000,000 de registros. Tengo demasiadas malas elecciones de diseño hechas por personas que piensan que un pequeño conjunto de datos está bien para el desarrollo.

Aquí, no permitimos que los desarrolladores tengan una base de datos separada en su cuadro (que normalmente limita el tamaño de la base de datos por no ser un servidor conectado a SAN), sino que deben trabajar contra la base de datos dev se renueva periódicamente desde prod (y luego se ejecutan todos los scripts nuevos del dev) para mantener los datos del tamaño correcto. Creo que es importante que su entorno de base de datos dev coincida lo más posible con la configuración del equipo, el tamaño de la base de datos, etc. Nada más frustrante que pasar mucho tiempo desarrollando algo que o no funcionará en absoluto o tiene que ser retirado inmediatamente porque está ralentizando demasiado el sistema.

Salto de mi tribuna ahora.

Answer 2

Uso DataConstructor pero estoy predispuesto porque lo escribí.

Answer 3

Es una buena idea comprobar las secuencias de comandos, ya que el control de código fuente es más adecuado para trabajar con archivos de texto, en lugar de archivos binarios. Las diferencias en los archivos de script se pueden revisar fácilmente como parte del resto de los cambios de código relacionados con el cambio de la base de datos. Además de verificar los scripts de la base de datos, también verificamos una instantánea del esquema de la base de datos. Esta instantánea del esquema de la base de datos nos permite verificar que el esquema en producción coincida con el esquema esperado para la versión determinada del producto. Además de eso, la instantánea del esquema de la base de datos es una forma útil para buscar columnas y tablas usando un editor de texto sin formato.

Answer 4

Try SQL examinador: How to keep your database under version control

Answer 5

Usted podría utilizar una herramienta como Liquibase para administrar los scripts de base. Es realmente un marco de actualización de la base de datos, por lo que mantendrá un registro de los pasos que ya se han ejecutado, por lo que cuando desee actualizar la producción, por ejemplo, solo ejecutará los nuevos pasos.