Imagine un escenario donde usted desea enviar sus bases de datos al control de versiones rápida y fácilmente, incluyendo todos los objetos del esquema y los datos desde ciertas tablas de código que no cambiarán, también conocidas como datos Estáticos. Luego, una vez que haya trasladado su base de datos exitosamente al control de versiones, puede actualizar el repositorio en las noches con cualquiera o todos los objetos cambiados. De esta manera, usted ha añadido automáticamente su base de datos al control de versiones, sin tener que preocuparse acerca de la integración directa, las entradas, salidas, etc., esencialmente proveyendo mucho de las “ganancias” de la integración de la base de datos con el control de versiones, con poco del “costo”. Este artículo describirá cómo construir este sistema de integración de bases de datos SQL al control de versiones usando una herramienta de terceros, ApexSQL Script.

En el caso del desarrollo de bases de datos, de la misma manera que para el desarrollo de aplicaciones, siempre hay tareas como desarrollar una nueva característica, arreglar un error del lanzamiento actual, experimentar con código para mejorar el desempeño, la usabilidad en cualquier forma y más. Por todo esto, es esencial que cualquier cambio que haya sido enviado, pero no inmediatamente, sea segregado a un ambiente aislado, de modo que no afecte al resto del equipo o el código principal. Por ejemplo, cuando se está desarrollando una nueva característica, puede que requiera que muchos cambios se envíen antes de la característica, o incluso una parte funcional de la característica se vuelve útil, de modo que el resto del equipo pueda aplicarla en sus copias locales de la base de datos. Sin tener el aislamiento mientras se desarrolla, el equipo no tendrá la libertad de codificar sin tener que preocuparse acerca de romper el código base existente.

Dividir una tabla moviendo un conjunto de columnas a una nueva taba es llamado particionamiento vertical. El particionamiento horizontal es tener diferentes tablas con las mismas columnas, pero conteniendo diferentes (distintos) conjuntos de filas.

Tener un equipo de desarrolladores trabajando en la misma base de datos (compartida) puede ser desafiante por muchas razones. Es crítico asegurar que todos los cambios están apropiadamente rastreados y que cada desarrollador está informado acerca del estado de los objetos actualmente usados por el resto del equipo. Cuando se usa una base de datos compartida, todos los cambios serán aplicados contra la base de datos antes que sean enviados al repositorio.

Tener una base de datos SQL Server bajo control de fuente se está convirtiendo rápidamente en la norma versus la excepción en muchos equipos de desarrollo de software. Usar cualquier modelo de desarrollo (dedicado o compartido), requiere que el equipo establezca un flujo de trabajo un conjunto de reglas. El modelo dedicado permite al desarrollador actuar como una parte independiente del proceso principalmente en el caso de que el servidor/repositorio esté abajo. En este caso, el equipo puede continuar trabajando sin obstáculos. Este artículo se enfocará en usar el modelo de desarrollo dedicado para el control de código fuente en SQL Server.