cambios de versión para procedimientos almacenados

Question

que tienen una aplicación que se basa en gran medida en los procedimientos almacenados de SQL (2005/2008). Estamos haciendo una actualización menor que modificará 25-35 de estos procedimientos almacenados. La aplicación es tal que ambas versiones del procedimiento almacenado deben estar disponibles.

Esta es la versión principal 4 de la aplicación y, por lo general, hemos podido modificar por completo la estructura de datos para ir con cada nueva versión. Sin embargo, en este caso, no podemos hacer eso.

Éstos son mis 2 opciones Yo he llegado con

1. Haga un "2" versión de cada procedimiento almacenado. Si tuviera un procedimiento llamado getUser cree un getUser2. La desventaja de esto es que el n. ° de procedimientos almacenados crecerá exponencialmente con cada cambio de versión

2. Agregue un parámetro @version a cada procedimiento almacenado que por defecto es v1. Esto mantendría baja la cantidad de procedimientos almacenados pero inflaría cada procedimiento almacenado

¿Alguien tiene alguna idea al respecto? ¿Alguna otra idea inteligente?

Cody

Answer 1

yo no crear dos archivos diferentes eso es seguro. Tal vez en su control de fuente debe hacer una rama de todas sus versiones y luego una nueva rama con su próxima versión, luego puede incluir ambas ramas como carpetas separadas en su sistema y su lógica de negocios apunta a la ubicación correcta.

Esta solución puede ser un poco descuidada, pero creo que es la menor de varios males.

Independientemente, en realidad el versionado de su código de procedimiento almacenado es una obligación definitiva en mi opinión.

Answer 2

Sugeriría la segunda opción que proporcionó. Use un parámetro de versión. Esto es lo que hacen los servicios web para que no rompan el código de aplicaciones que comenzó a usar la API hace mucho tiempo, pero la API se actualiza en algún momento.

Apuesto a que hay una lógica que es la misma entre las dos versiones que puedes abstraer en la parte inferior del proceso o algo así. O potencialmente crear funciones para los elementos comunes y llamar a esas funciones dentro de sus grandes bloques/Swtich IF.

Answer 3

Aprovecharía esta oportunidad para pasar de los procedimientos almacenados a un ORM u otro enfoque. Ambos de sus soluciones propuestas requeriría algún tipo de cambio de código para decidir qué procedimiento usar almacena. En lugar de eso, decidí si usar los procedimientos almacenados o el ORM. También crearía planes para eliminar la mayoría de los procedimientos almacenados.

He visto un montón de códigos incorrectos y sistemas dañados en mi carrera, pero nada me hace perder la esperanza de que un proyecto se pueda salvar como ver GetItemFromLots_2_Temp_2 en la lista de procedimientos almacenados. Los métodos múltiples son mucho más bonitos y fáciles de mantener que los múltiples procedimientos almacenados.

(Para otras personas que aman los procedimientos almacenados. No estoy diciendo que sean malas. Estoy seguro de que hay métodos inteligentes para manejar este tipo de cosas usando procedimientos almacenados pero, si se utilizara este enfoque, la pregunta no se habría hecho.)

Answer 4

Modifique los procedimientos almacenados existentes para que la nueva lógica se ejecute condicionalmente, solo cuando se llame al proceso en aquellas circunscripciones donde se debe ejecutar la nueva lógica ... Si el nuevo proceso tuviera una interfaz ligeramente diferente (establecer de parámetros de sProc) entonces usted puede hacerlos opcionales y usar la presencia o ausencia del parámetro un interruptor para controlar qué trozo de código se ejecuta dentro del proceso ...

Cuando la vieja lógica ya no es necesaria, puede simplemente eliminarlo de los sProcs

Answer 5

Iría por la opción de dos archivos por las siguientes dos razones:

• La firma, que es el número de parámetros puede cambiar entre las versiones
• Cada procedimiento almacenado sería más simple, por lo tanto, menos posibilidades de errores de todo código condicional

Answer 6

Solíamos utilizar procedimientos almacenados ampliamente en mi compañía, pero (en su mayoría) se han alejado de ellos hacia ORM últimamente.

Todavía los usamos, y nuestro control de versiones es el mismo que antes: cada vez que modificamos los procedimientos almacenados que quedan (que solo unas pocas personas tienen derecho a hacer), guardamos el SQL y almacenamos el archivo .sql en nuestro control de versiones.

Es imperfecto y perdemos mucha de la integración que tenemos entre el control de código fuente y nuestros archivos de código (ya que no hay integración de servidor SQL en TFS) pero es mejor que ningún control de fuente.

EDITAR - y, por supuesto, esto solo funciona si ya no necesita usar la versión anterior del proceso almacenado, ya que no existirá en forma ejecutable.

Answer 7

Otro enfoque interesante sería almacenar todo el código para sus procedimientos almacenados en una tabla de base de datos, junto con la versión del código. Luego tiene un proceso "front-end" que maneja las solicitudes y luego, dependiendo de la versión, crea dinámicamente un proceso y lo ejecuta. A continuación, puede soltar el proceso cuando haya terminado.

Simplemente una sugerencia fuera de la pared pero puede funcionar para usted.