¿Cómo separar la lógica y los datos de programación en MS SQL Server 2005?

Question

Estoy desarrollando un sitio web basado en datos y una gran cantidad de lógica de programación reside en procedimientos almacenados en bases de datos y funciones de bases de datos. Me encontré cambiando bastante las funciones/procesos almacenados para corregir errores o agregar nuevas funcionalidades. Los datos (tablas) se han mantenido casi intactos.

El problema que estoy teniendo es hacer el seguimiento de versiones de proc/funciones almacenadas. Actualmente estoy incrementando la versión de la base de datos completa cuando hago un conjunto de cambios. Como los datos son enormes (10 Gb), tengo problemas para ejecutar la versión de desarrollo y lanzar versiones de bases de datos en paralelo.

deseo de poner todos los procs almacenados y funciones en una sola base de datos y mantener los datos en una base de datos, de modo que pueda manejar mejor los cambios.

estoy seguro de que otros habrían encontrado similares sugerir y solicitar sugerencias sobre cómo manejar mejor esta situación.

Answer 1

Usted puede simplemente la versión del esquema de vertederos. En combinación con la expansión de palabras claves de control de origen (como lo sugiere Rawheiser), simplemente eche un vistazo a la versión que tiene en la base de datos, genere un diff y aplíquelo.

Además, hay varias herramientas excelentes para comparar bases de datos y sus esquemas, generar scripts DDL etc .: Workbench SQL, Power Architect, DDLUtils y Redgate SQL Compare, por nombrar algunos. Es probable que SQL Compare funcione mejor con SQL Server, aunque todos los demás son FOSS y proporcionan un ROI más alto (en términos de tiempo de aprendizaje y qué puede hacer con ellos) ya que son plataformas independientes y RDBMS independientes.

Finalmente, tengo que decir ... Entiendo que los resultados inmediatos que obtienes con la lógica en el DB son tentadores, pero si has ido más allá de más de un par de procedimientos en la base de datos, estás configurando te molesta bastante, revisando lo que fácilmente se convierte en código de espagueti y bloqueando tu aplicación a un único proveedor de bases de datos. Puede que tenga sus razones, pero he estado allí y no me gustó mucho. La lógica puede vivir muy bien en una capa diferente.

Answer 2

Para el control de origen que tiene varias opciones:

1. utilizar un Visual Studio Database project.

2. uso de SQL Server 2005 de soporte incorporado para source control

3. Usar una tercera parte de herramienta como SQL Compare

OMI Opción 1. es preferible.

Answer 3

También recomendaría el uso de expansión de palabras clave de control de origen en los procedimientos almacenados ($ Versión: $)

esa manera se puede calcular visualmente, grep, syscomments de búsqueda, etc para ver cuál es la versión que tiene en su base de datos desplegado.