¿Cómo se manejan los cambios en el código de procedimiento almacenado de múltiples aplicaciones usando la misma base de datos?

Question

La base de datos en nuestro entorno está siendo compartida por 2 entornos/aplicaciones diferentes. De las 2 aplicaciones, las primeras dicen que A se actualiza con frecuencia, mientras que la segunda aplicación B no se actualiza con tanta frecuencia.

Así que aquí la situación es cuando la aplicación A se actualiza con código nuevo, principalmente procedimientos almacenados, a veces puede afectar y romper la segunda aplicación B, que está siendo actualizada por otro equipo y no se actualiza con demasiada frecuencia. Entiendo que esta no debería ser la manera correcta de manejarlo y que no actualizar ambos entornos juntos puede ser desastroso. Esto está sucediendo porque las aplicaciones A & B están siendo manejadas por diferentes equipos.

¿Cómo manejarías esta situación elegantemente?

De Aplicación B las precauciones que pude tomar son - Recuperación de datos en código - La mejor manera al recuperar datos sería para comprobar si hay columnas en blanco/nulo, por lo que si las nuevas columnas se agregan mediante la aplicación A, que pueden ser ignorado por la aplicación B. Recuperar datos en SQL - Dentro del procedimiento, se puede manejar usando parámetros opcionales.

Pero cuando el código C# llama a un procedimiento, se supone que estamos pasando valores de param, y si hay nuevos parámetros agregados, se rompe. ¿Hay alguna manera de asegurarse de que si falta el parámetro de llamada, debe ignorarse (desde C# o SQL Server)?

Mis programas de investigación -

1. que puedo recuperar la lista de parámetros del procedimiento almacenado en primer lugar, y luego llamar al procedimiento utilizando esa lista para recorrer y comprobar si existe el parámetro. Para que incluso si la aplicación A agrega nuevos parámetros, la aplicación B pueda manejarla automáticamente. Esto podría hacerse usando DeriveParameters en C# o una consulta SQL para obtener la lista de parámetros.

2. Cambie todos los SPROC para tomar los parámetros en forma de CSV. Y divídalos en el SPROC y úselos en consecuencia. Esto suena cojo para cientos de sprocs existentes.

Una vez más, como ya he dicho - esto es imposible parece una buena solución, y si has tenido una situación similar, lo diferente que habría manejado esto? ¿Existe un marco, que no sé cuál podría funcionar en este escenario?

Medio Ambiente - ASP.NET/C# 4.0, SQL Server 2008 R2

EDITAR - Permítame rehacer y proporcionar un poco más detalles aquí.

1. Aplicación/Equipo A cambia el código, pero sólo C# código se extenderá a la producción, sin embargo, no los cambios de base de datos. Aquí es donde está la diferencia. Y el código DB entraría solo con la próxima versión.

2. La aplicación/Equipo B tiene el código más reciente, pero los cambios en la base de datos todavía no están en producción y aún utiliza la base de datos anterior.

Answer 1

¿Hay razones por las que no puede asignar valores predeterminados a los nuevos parámetros? p.ej.

CREATE PROCEDURE xxx 

    @OldParam int 
    ,@NewParam int = 0 

AS 

    <etc> 

La aplicación "A" pasa en ambos parámetros.

La aplicación "B" se escribió cuando el proceso solo tenía un parámetro, y solo lo llama con el único parámetro que importa. Con la nueva versión, el segundo parámetro no se pasará, por lo que recoge el valor predeterminado de 0 ... y el procedimiento se codifica de manera adecuada. (Valores predeterminados especiales NULL o se podrían utilizar para "marcar" las llamadas de sistema más antiguo.)

---

[Agregado]

Una posible solución a largo plazo habría que añadir algún tipo de sistema de la versión a la base de datos que se actualiza cada vez que se actualiza la base de datos.

• Cuando una aplicación se pone en marcha, se pone la versión actual

• Si hay llamadas cuyos parámetros difieren entre versiones, comprobar y formatos adecuadamente en el momento de la llamada, como

  Si versión < 3 a continuación, llamar proc con 1 parámetro

  proc llamada Else con 2 parámetros

Esto sería quisquilloso y complicado de seguir y mantener a lo largo del tiempo, pero si no puede actualizar todos los sistemas (A, B y la base de datos) al mismo tiempo, sus opciones son limitadas.

Answer 2

Tal vez cada aplicación podría tener su propio conjunto de procedimientos almacenados, por lo que no se molestan entre sí.

Answer 3

No creo que haya una solución elegante para eso, pero, como no se puede reescribir toda la aplicación, así ... con su escenario, duplicaría todos los SP de las aplicaciones y los colocaría en esquemas separados.

Crea diferentes usuarios en tu base de datos y deja que cada aplicación se conecte a la base de datos con su propio usuario. El usuario de base de datos para la aplicación A, su rol, no debe tener permisos para ejecutar los SP que pertenecen al otro esquema, y ​​lo mismo para el usuario de base de datos para la aplicación B.

Deberá reescribir algún código del aplicaciones para cambiar las cadenas de conexión, por supuesto.