Reutilización de procedimientos almacenados de SQL en todas las aplicaciones

Question

Tengo curiosidad acerca de los enfoques de la gente sobre el uso de procedimientos almacenados en una base de datos a la que acceden muchas aplicaciones.Específicamente, ¿tiendes a mantener diferentes conjuntos de procedimientos almacenados para cada aplicación, intentas utilizar un conjunto compartido o haces una combinación?

Por un lado, la reutilización de SP permite menos cambios cuando hay un cambio de modelo o algo similar e idealmente menos mantenimiento.Por otro lado, si las necesidades de las aplicaciones divergen, los cambios en un procedimiento almacenado para una aplicación pueden dañar otras aplicaciones.Debo señalar que en nuestro entorno cada aplicación tiene su propio equipo de desarrollo, con mala comunicación entre ellos.Sin embargo, el equipo de datos tiene una mejor comunicación y su tarea principal es escribir el procedimiento almacenado.

¡Gracias!

Answer 1

Todo depende de tu estrategia de abstracción.¿Los procedimientos almacenados se tratan como un punto discreto de abstracción o se tratan simplemente como otra parte de la aplicación que los llama?

La respuesta le dirá cómo gestionarlos.Si son una abstracción discreta, se pueden compartir, ya que si necesita nueva funcionalidad, agregará nuevos procedimientos.Si son parte de la aplicación que los llama, no se deben compartir.

Answer 2

Los procedimientos almacenados deben crearse en función de los datos que desea devolver, no de la aplicación que realiza la solicitud.Si tiene un procedimiento almacenado que es GetAllItems, debería devolver todos los elementos de la base de datos.Si una de las aplicaciones desea obtener todos los elementos por categoría, cree GetAllItemsByCategory.No hay ningún motivo para que las reglas comerciales de un procedimiento almacenado cambien según la aplicación que solicita los datos.

Answer 3

Mi experiencia ha sido que tener SP compartidos por múltiples aplicaciones es una causa de dolor.De hecho, yo diría que tener una base de datos a la que acceden directamente más de una aplicación no es la mejor arquitectura a largo plazo.

El patrón que recomiendo y he implementado es que solo una aplicación debe "poseer" cada base de datos y proporcionar API (servicios, etc.) para que otras aplicaciones accedan y modifiquen los datos.

Esto tiene varias ventajas:

1. La aplicación propietaria puede aplicar cualquier lógica empresarial, registro, etc.para asegurarse de que permanezca estable
2. Si se cambia el esquema, se conocen todas las interfaces y se pueden probar para asegurarse de que las aplicaciones externas sigan funcionando.

Answer 4

Los procedimientos almacenados deben exponer reglas comerciales que no cambian según la aplicación que los utiliza.Esto permite que las reglas se almacenen y actualicen una vez en lugar de cada lugar donde se utilizan, lo cual es una pesadilla.

Answer 5

Piénsalo de esta manera:sus procedimientos almacenados tratan sobre los datos que se encuentran debajo de ellos y realmente no deberían conocer las aplicaciones que se encuentran encima de ellos.Es posible que una aplicación necesite leer o actualizar datos de una manera que otra no, por lo que una usaría SP que la otra no.

Si fuera mi aplicación/base de datos/etc., y los cambios en un SP para mejorar una aplicación arruinaran otra, consideraría esa evidencia de un problema de diseño más profundo.

Answer 6

Creo que la última parte de su pregunta se respondió sola.

Con una comunicación ya deficiente, compartir procedimientos entre equipos de desarrollo solo aumentaría los posibles puntos de falla y podría causar dificultades a cualquiera de los equipos.

Si estoy en el mismo equipo trabajando en varios proyectos, ahorraremos algo de tiempo y compartiremos procedimientos, pero normalmente he descubierto que una pequeña duplicación (algunos procedimientos aquí y allá) ayuda a evitar los cambios/duplicaciones catastróficos necesarios más adelante cuando las aplicaciones empezar a divergir.

LordScarlet también señala un elemento clave: si es genérico y no comparte la lógica empresarial, no debería ser un problema.

Answer 7

Siempre que tuviéramos procedimientos almacenados que fueran comunes a múltiples aplicaciones, crearíamos una base de datos solo para esos procedimientos (y vistas y tablas, etc.).Esa base de datos (la llamamos "base") tendría entonces un desarrollador (o equipo) responsable de ella (mantenimiento y pruebas).

Si un equipo diferente necesitara una nueva funcionalidad, podría escribirla y el desarrollador base la implementaría en la base de datos base o sugeriría una forma más sencilla.

Answer 8

Intentamos utilizar un único proceso almacenado compartido siempre que sea posible, pero también nos encontramos con la situación que usted describe.Lo manejamos agregando un prefijo de aplicación a los procesos almacenados (ApplicationName_StoredProcName).

A menudo, estos procesos almacenados llaman al proceso almacenado centralizado o "maestro", pero este método deja espacio para cambios específicos de la aplicación en el futuro.

Answer 9

No creo que tenga sentido compartir Sprocs entre múltiples aplicaciones.

Puedo ver el caso de compartir una base de datos en aplicaciones relacionadas, pero presumiblemente esas aplicaciones están separadas en gran parte porque tratan los datos de manera muy diferente entre sí.

Usar la misma arquitectura podría funcionar en todas las aplicaciones, pero imagine intentar usar la misma capa de lógica empresarial en múltiples aplicaciones."¡Pero espera!" Dices: "Eso es una tontería ...Si uso el mismo BLL, ¿por qué debería tener una aplicación separada?¡Ellos hacen la misma cosa!"

QED.

Answer 10

Lo ideal es utilizar un proceso, no varias versiones.Si necesita versiones por cliente, investigue la idea de 1 db por cliente en lugar de 1 db para todos los clientes.Esto también permite una interesante puesta en escena de bases de datos en diferentes servidores (asigne los de uso más grande/pesado a servidores más grandes, mientras que los más pequeños pueden compartir hardware)

Answer 11

Si busca la posibilidad de compartir el código SQL, intente crear una biblioteca de funciones abstractas.De esta manera, podría reutilizar parte del código que hace cosas genéricas y mantener la lógica empresarial separada para cada aplicación.Se podría hacer lo mismo con las vistas: podrían mantenerse bastante genéricas y útiles para muchas aplicaciones.

Probablemente descubrirá que no hay muchos usos para los procedimientos almacenados comunes a medida que avanza.

Dicho esto, una vez implementamos un proyecto que trabajaba con una base de datos heredada muy mal diseñada.Hemos implementado un conjunto de procedimientos almacenados que facilitaron la recuperación de información.Cuando otras personas de otros equipos quisieron usar la misma información, refactorizamos nuestros procedimientos almacenados para hacerlos más genéricos, agregamos una capa adicional de comentarios y documentación y permitimos que otras personas usaran nuestros procedimientos.Esa solución funcionó bastante bien.

Answer 12

Muchos procedimientos almacenados son independientes de la aplicación, pero puede haber algunos que dependan de la aplicación.Por ejemplo, los procedimientos almacenados CRUD (Crear, Seleccionar, Actualizar, Eliminar) pueden abarcar todas las aplicaciones.En particular, puede incluir lógica de auditoría (a veces se realiza en desencadenadores, pero hay un límite en lo complicado que puede llegar a ser en los desencadenadores).Si tiene algún tipo de arquitectura estándar en su tienda de software, el nivel medio puede requerir un procedimiento almacenado para crear/seleccionar/actualizar/eliminar de la base de datos independientemente de la aplicación, en cuyo caso el procedimiento es compartido.

Al mismo tiempo, puede haber algunas formas útiles de ver los datos, es decir, GetProductsSoldBySalesPerson, etc.que también será independiente de la aplicación.Es posible que tenga varias tablas de búsqueda para algunos campos como departamento, dirección, etc.por lo que puede haber un procedimiento para devolver una vista de la tabla con todos los campos de texto.Es decir, en lugar de SalesPersonID, SaleDate, CustomerID, DepartmentID, CustomerAddressID, el procedimiento devuelve una vista SalesPersonName, SaleDate, CustomerName, DepartmentName, CustomerAddress.Esto también podría usarse en todas las aplicaciones.Un sistema de relación con el cliente necesitaría el nombre/dirección/otros atributos del cliente, al igual que un sistema de facturación.Entonces, algo que hiciera todas las uniones y obtuviera toda la información del cliente en una consulta probablemente se usaría en todas las aplicaciones.Es cierto que crear formas de ver los datos es el dominio de una vista, pero a menudo la gente utiliza procedimientos almacenados para hacerlo.

Básicamente, al eliminar de su tabla, necesita eliminar de otras 3 o 4 tablas para garantizar la integridad de los datos.¿Es la lógica demasiado complicada para un disparador?Entonces puede ser importante contar con un procedimiento almacenado que utilicen todas las aplicaciones para realizar eliminaciones.Lo mismo se aplica a las cosas que deben hacerse en la creación.Si hay uniones comunes que siempre se realizan, puede tener sentido tener un procedimiento almacenado para realizar todas las uniones.Luego, si luego cambia las tablas, puede mantener el procedimiento igual y simplemente cambiar la lógica allí.

Answer 13

El concepto de compartir un esquema de datos entre múltiples aplicaciones es complicado.Invariablemente, su esquema se ve comprometido por motivos de rendimiento:desnormalización, qué índices crear.Si puede reducir el tamaño de una fila a la mitad, puede duplicar el número de filas por página y, probablemente, reducir a la mitad el tiempo que lleva escanear la tabla.Sin embargo, si solo incluye características "comunes" en la tabla principal y mantiene datos de interés solo para aplicaciones específicas en tablas diferentes (pero relacionadas), debe unirse en todas partes para volver a la idea de "tabla única".

Más índices para admitir diferentes aplicaciones harán que el tiempo para insertar, actualizar y eliminar datos de cada tabla sea cada vez mayor.

El servidor de la base de datos a menudo también se convierte en un cuello de botella, porque las bases de datos no pueden equilibrar la carga.Puede dividir sus datos en varios servidores, pero eso también se vuelve muy complicado.

Finalmente, el grado de coordinación requerido suele ser enorme, sin duda con peleas entre diferentes departamentos sobre qué requisitos tienen prioridad, y los nuevos desarrollos se estancarán.

En general, el modelo de 'silo de datos aislados por aplicación' funciona mejor.Casi todo lo que hacemos (trabajo para una empresa de software por contrato) se basa en importar y exportar datos a otros sistemas, con las bases de datos propias de nuestras aplicaciones.

Bien puede ser más fácil en sistemas de soporte de decisiones/almacenamiento de datos;Generalmente trabajo en sistemas OLTP donde el rendimiento de las transacciones es primordial.