Argumentos a favor / en contra de Business Logic en procedimientos almacenados

Question

¿Cuáles son los argumentos a favor y en contra de la lógica empresarial en los procedimientos almacenados?

Answer 1

Contra procedimientos almacenados: lógica empresarial en el espacio de programación

Coloco un alto valor en el poder de expresión, y no encuentro que el espacio SQL sea tan expresivo. Use las mejores herramientas que tenga a mano para las tareas más apropiadas. Jugar con la lógica y los conceptos de orden superior se realiza mejor al más alto nivel. En consecuencia, el almacenamiento y la manipulación masiva de datos se realiza mejor a nivel del servidor, probablemente en procedimientos almacenados.

Pero depende. Si tiene varias aplicaciones que interactúan con un mecanismo de almacenamiento y desea asegurarse de que mantenga su integridad y flujo de trabajo, debe descargar toda la lógica en el servidor de la base de datos. O prepárese para administrar el desarrollo concurrente en múltiples aplicaciones.

Answer 2

Estoy completamente en contra de eso. Una de las principales razones es la primera razón por la que Earino declaró: vive en un solo lugar. No puede integrarlo en el control de fuente muy fácilmente. Es casi imposible tener dos desarrolladores trabajando en un proceso almacenado al mismo tiempo.

Mi otra queja principal es que SQL simplemente no es muy bueno para representar una lógica compleja. No tiene un concepto de alcance, el código tiende a ser pegado porque hay menos capacidad de reutilizar el código (a diferencia de un lenguaje OO).

Debe dar a los desarrolladores acceso a la base de datos para desarrollarla allí. En muchas organizaciones que he trabajado en los datos, las personas están en un mundo diferente al de los desarrolladores, con diferentes permisos, etc. Mantener a los desarrolladores fuera de la base de datos en estos casos sería más difícil.

Answer 3

Soy de la escuela de pensamiento que dice que mientras la lógica de negocios:

• vive en un lugar
• donde está debidamente documentado
• se proporciona acceso adecuado a través de servicios que se pueden acoplar libremente
• a través de una interfaz abstracta publicada

No me importa si la lógica vive en un procedimiento almacenado, en un nivel medio J2EE, en un sistema experto de clips o donde sea. No importa dónde almacene nuestra lógica de negocios, la & Quot; ley de conservación de la miseria & Quot; va a garantizar que alguien diga que fue una idea equivocada porque el componente / repositorio X debe cambiarse por tecnología / método Y.

Answer 4

Algunas ideas: Tenga en cuenta que esta es una respuesta centrada en Java, pero es la mayor parte de mi experiencia reciente (últimos 10 años)

(1) Desarrollo concurrente por un (gran) equipo de desarrolladores. Si su aplicación es lo suficientemente compleja como para que cada desarrollador no pueda configurar su propia versión privada de la base de datos (con enlaces atendidos / datos de referencia / etc ...) es muy difícil tener un EQUIPO completo de desarrolladores trabajando en ¿El mismo conjunto de paquetes PL-SQL (por ejemplo) al mismo tiempo almacenados en un DEVL DB compartido? Entonces, tu estás atascado (mi experiencia) trabajando en una base de datos con procedimientos no válidos / desajuste de código en las tablas a medida que las personas realizan cambios ...

Como arquitecto de Java, creo que es mucho más fácil que cada desarrollador tenga una instancia privada de JBoss en su escritorio y trabaje fácilmente en su propio conjunto de funcionalidades, e integre a su propio ritmo sin afectar a todos los demás ... lo que trae yo a ...

(2) Conjuntos de herramientas de integración continua Si bien existen algunos 'conceptos' similares en el mundo de DB, mi experiencia me ha demostrado que la combinación de (estoy eligiendo mis favoritos actuales mejores de la raza aquí):

• mvn - sistema de compilación
• junit - prueba unitaria automatizada
• nexus - gestor de repositorios (gestiona la versión, instantáneas y lanzamientos de ciclos de vida de artefactos)
• hudson - servidor de compilación ci
• sonar - herramienta de análisis estático / informes de cobertura de código / MUCHO más

Ejecutar un proyecto grande utilizando todo lo anterior (herramientas gratuitas) permite una manera consistente / fácil de entregar XP a las masas y aplicar controles de calidad a todo el personal de TI. Oracle / PL-SQL no tiene los conjuntos de herramientas para que coincidan

(3) herramientas / bibliotecas / etc. Java tiene acceso a un sorprendente conjunto de servicios que otras plataformas no pueden tocar, algunos gratuitos y otros no. incluso los básicos, como log4j (sí, lo tienen para PL / SQL, pero por supuesto ... no es lo mismo) permite cosas como permitir a los desarrolladores crear registros ajustables de forma flexible que se pueden cambiar sobre la marcha (perfecto para la copia) . Documentación de API automatizada (a través de javadoc). Informes automatizados de cobertura de pruebas unitarias. IDE increíbles (Eclipse) con depuradores integrados / despliegue automático a servidores de aplicaciones. Una API para interactuar con cada tipo de servicio bajo el sol, bibliotecas de código abierto para hacer CUALQUIER COSA y 100% de soporte por parte de cada proveedor

(4) reutilización de servicios. lo que alguien comentó es verdad. Si tiene reglas de negocio basadas en datos para trabajo pesado, entonces puede argumentar que estas deberían vivir en la capa de base de datos. ¿Por qué? para evitar que todos los niveles intermedios tengan que duplicar esa lógica.

Pero lo mismo puede decirse de las reglas de negocio que no están basadas en datos o son lo suficientemente complejas como para que OO sea una opción más natural . Si pega TODA la lógica de negocios en la base de datos, entonces están disponibles solo a través de la base de datos.

• ¿Qué sucede si desea que se realice la validación en el nivel de cliente o aplicación intermedia y guardar un viaje de ida y vuelta a la base de datos?
• ¿Qué sucede si desea almacenar en caché los datos de solo lectura en el nivel medio (para el rendimiento) y hacer que las reglas comerciales se ejecuten contra los datos en caché?
• ¿Qué sucede si tiene un servicio de nivel medio que no requiere acceso a la base de datos o si tiene un cliente que puede proporcionar sus propios datos?
• ¿Qué sucede si la parte dependiente de los datos de las reglas comerciales necesita acceder a servicios externos? Luego termina con una lógica empresarial fragmentada que se ve así:

i

retCode = validateSomeDate(date);
if (retCode == 1) then
   evaluateIfCustomerGetsEmail(...)//probably more stored proc invocations here...
   sendEmailMsg(....)
else if (retCode == 2) then
   performOtherBizLogicStuf(...) //again, may need data, may not need data
   triggerExternalsystemToDoSomething(...) //may not be accessible via PL/SQL 
fi

Estoy seguro de que todos hemos visto sistemas escritos como el anterior y tuvimos que depurarlos a las 2AM. Es extremadamente difícil obtener un sentido coherente de un proceso complejo cuando la lógica de negocios está fragmentada entre niveles y, en algunos casos, resulta imposible mantenerla.

Answer 5

" No puede integrarlo en el control de fuente muy fácilmente. " - si coloca el código que crea el proceso almacenado en un script que está controlado por la versión, esa objeción desaparece. Si sigue las ideas ágiles de la base de datos de Scott Ambler, eso es exactamente lo que debería estar haciendo.

No todos los desarrolladores son buenos modeladores de datos. Puedo pensar en esquemas horribles creados por desarrolladores que pensaron que un pequeño conocimiento de SQL los convirtió en expertos en bases de datos. Creo que es muy valioso tener desarrolladores trabajando con DBA y modeladores de datos.

Si solo una aplicación usa la base de datos, diría que la lógica de negocios puede aparecer en el nivel medio. Si muchas aplicaciones comparten la base de datos, quizás sea mejor ponerla en la base de datos.

SOA ofrece una vía intermedia: los servicios poseen sus datos. Solo el servicio tiene acceso a los datos; acceder a los datos significa pasar por el servicio. En ese caso, es posible poner las reglas en cualquier lugar.

Las aplicaciones van y vienen, pero los datos permanecen.

Answer 6

Una razón más para NO almacenar la lógica de negocios en sprocs: capacidades de escalado limitadas de la base de datos. Es una situación muy común en la que su base de datos es su cuello de botella, por eso es una buena idea tomar la mayor cantidad de carga posible de la base de datos.

Answer 7

Mis pocas observaciones:

A favor de los procedimientos almacenados:

• después de algún tiempo de vida del proyecto, en la mayoría de los casos, el cuello de botella es la base de datos, no el servidor web, y los procedimientos almacenados son mucho, mucho más rápidos

• usar sql profiler con consultas sql generadas por ORM es muy difícil; esto es fácil con los procedimientos almacenados

• puede implementar una solución para el procedimiento almacenado al instante, sin una ventana de servicio

• para el rendimiento, es más fácil optimizar un procedimiento almacenado que el código ORM

• puede tener muchas aplicaciones que usan los mismos db / procesos almacenados

• cualquier escenario de datos complejos es un voto para procedimientos almacenados

A favor de la aplicación / ORM:

• puede usar el repositorio de código (con los procedimientos almacenados todavía es posible pero costoso)

• el lenguaje java / c # es una mejor herramienta para expresar la lógica empresarial

• java / c # es más fácil de depurar (excepto el sql ORM generado dinámicamente)

• independencia del motor de base de datos (sin embargo, esto no es muy probable que un proyecto cambiar la base de datos a otra)

• ORM proporciona un modelo de datos que es fácil de usar

En mi opinión: para proyectos grandes, vaya a procedimientos almacenados, para los demás, la aplicación / ORM funcionará bien.

Al final del día, lo único que importa es la base de datos.

Answer 8

La lógica empresarial debe encapsularse en un solo lugar. Podemos garantizar que la lógica siempre se ejecuta y se ejecuta de manera consistente. Usando clases que toda actividad que involucra una entidad en la base de datos debe ejecutarse, podemos garantizar que toda la validación se ejecute correctamente. Hay un lugar para este código y cualquier desarrollador en el proyecto puede abrir fácilmente esta clase y ver la lógica (debido a que la documentación puede y se desactualiza, el código es la única forma confiable de documentación).

Esto es difícil de hacer con los procedimientos almacenados. Es posible que tenga más de un sproc que se ocupe de las mismas tablas. El encadenamiento de múltiples sprocs juntos para que la lógica reside en uno solo se vuelve difícil de manejar. Esa es la huelga uno. ¿Cómo se determina & Quot; ¿Cuáles son todas las reglas de negocio que rodean a la entidad X & Quot; dentro de la base de datos? Diviértete buscando miles de sprocs tratando de rastrear eso.

El número dos es que está vinculando su lógica empresarial a su mecanismo de persistencia. Es posible que no almacene todos sus datos en la misma base de datos, o algunos pueden residir en XML, etc. Este tipo de inconsistencia es difícil para el desarrollador.

La validación es difícil de realizar si la lógica reside solo en la base de datos. ¿Realmente llama a un sproc para validar cada campo en su formulario de entrada de datos? Las reglas de validación y la lógica de negocios son primos cercanos. ¡Esta lógica debería realizarse en el mismo lugar!

Answer 9

+: el servidor SQL a veces optimiza el código

+: Estás obligado a pasar parámetros, lo que limita los problemas de inyección de SQL

-: su código depende de una sola base de datos (algunos dbs ni siquiera tienen SP)

-: para cambiar el código necesita conectarse a la base de datos

-: la lógica no está bien organizada

Personalmente, estoy en contra, pero tuve que usarlo una vez en un sitio web muy ocupado. El uso de SP en MS SQL trajo enormes beneficios, pero una vez que implementé el almacenamiento en caché, esos beneficios ya no eran tan grandes.

Answer 10

Hay un dicho ...

Cuando todo lo que tienes es un martillo, todo parece un clavo.

En mi humilde opinión, no hay una respuesta única que se ajuste a todas las circunstancias. Me parece que muchas personas simplemente asumen que poner Business Logic en la base de datos siempre es incorrecto.

Se ha trabajado mucho para que el procesamiento de transacciones, especialmente las operaciones masivas, sea muy eficiente cuando se realiza en el lado de la base de datos. Además, la gestión del código en las bases de datos ha mejorado enormemente ya que se formaron la mayoría de las opiniones contra las bases de datos.

Creo que está mal considerar el servidor de bases de datos como una capa de persistencia. Si sus actividades de procesamiento son más eficientes cuando se realiza en el servidor de base de datos, hágalo allí.

Si no, entonces hazlos en otro lado.

Todo se reduce a lo que mejor se adapta a la aplicación en la que está trabajando en este momento, el equipo con el que está trabajando y el cliente que lo contrató.

Eso solo mis 2 centavos.

Answer 11

Puede probar la lógica empresarial de la unidad cuando está en una capa de lógica empresarial. Si está completamente separado, las operaciones de persistencia se pueden burlar, por lo que solo está probando el BL. Un proceso almacenado es mucho más difícil de mantener / depurar / prueba unitaria que p. linq y c #.

Answer 12

DBMS! = Servidor de aplicaciones

• Programación funcional (procedimiento almacenado DB) vs OOP. Para grandes programas, la OOP es simplemente estándar.
• IDE: eclipse, intellij, netbeans con todos los complementos para depuración, prueba y análisis solo funciona con lenguajes de programación reales. Herramientas de código estático .
• Control de versión si obtiene uno para PLSQL & amp; co. es genial. Si obtiene & Quot; sincronice la vista & Quot; directo de usted IDE - usted es realmente el afortunado.
• Escala tu sistema. Para el sistema DB es un infierno. Necesita hardware costoso para otros & Quot; nodos & Quot ;. Replicación. Y probablemente licencia para cada nodo. No olvides que todavía estás en & Quot; programación funcional & Quot; y el esfuerzo por comprender y mantener dichos sistemas es mucho mayor.
• Está atascado con su base de datos, intente cambiar o agregar una nueva de otra compañía
• Y así sucesivamente ...

El procedimiento almacenado para la lógica de negocios es una mala práctica hoy en día. Utilice la arquitectura de 3 niveles en su lugar.

Answer 13

El rendimiento mejorará enormemente moviendo la lógica a los procesos almacenados, especialmente si se trata de transacciones explícitas.

En mi experiencia, los desarrolladores de aplicaciones no son muy buenos para escribir código de base de datos optimizado, y no tienden a pensar en problemas de concurrencia o rendimiento.
Si la lógica empresarial se mantiene en la capa de aplicación, tiende a tener que desplazar grandes cantidades de datos (a menudo en muchos viajes de ida y vuelta) a través de la red, duplicarlos en la memoria en el servidor de base de datos, y al menos una vez en el servidor de aplicaciones, y realice una carga de procesamiento fila por fila en la aplicación mientras mantiene abierta una transacción. Luego, los desarrolladores de la aplicación se quejan de que la base de datos es lenta y sigue estancada.

Si coloca la lógica en la base de datos siempre que sea posible, tiende a pasar algunos parámetros a través de la red, las transacciones no se llevan a cabo mientras espera los recursos de la red y todo funciona como un rayo engrasado. Por supuesto, las bases de datos deben ir en el control de la fuente como cualquier otro código fuente ... hay muchas herramientas para eso.

Answer 14

@Nick " Estoy completamente en contra de eso. Una de las principales razones es la primera razón por la que Earino declaró: vive en un solo lugar. No puede integrarlo en el control de fuente muy fácilmente. Es casi imposible tener dos desarrolladores trabajando en un procedimiento almacenado al mismo tiempo. & Quot;

No es que esté argumentando a favor de poner la lógica empresarial en los procedimientos almacenados (todo lo contrario). Pero estas razones que presentas no tienen sentido. Un procedimiento almacenado es simplemente un artefacto sql / DDL que se puede almacenar en el control de origen, y que también es un artefacto de despliegue (es decir, algo entregado a la dba para su despliegue, de la misma manera que entregarías tu guerra / oído artefactos a los enlaces de TI / implementación) Uno o más desarrolladores pueden trabajar en el mismo procedimiento almacenado fuera del control de origen de la misma manera que lo harías con el código fuente antiguo: ramificando, versionando y fusionando.

Ahora, si la única copia del procedimiento almacenado (y los paquetes que los contienen) solo existe en la base de datos, entonces obviamente no puede controlar eso con el control de origen (y todos los problemas asociados a eso). Sin embargo, eso no es un problema de procedimiento almacenado, sino un problema de ineptitud con respecto a cómo usar ese código. Es igualmente una muestra de ineptitud como tener solo una copia de su código fuente viviendo en producción.

He trabajado en sistemas con grandes cantidades de código, tanto Java como PLSQL / DDL, y todos fueron versionados en clearcase. Todos fueron tratados como código fuente que sería compilado y desplegado con un proceso estricto, con diferentes equipos trabajando en ellos. Nunca tuve ningún problema como lo que estás describiendo.

Hay razones específicas del contexto para no poner la lógica de negocios en los procedimientos almacenados, pero estas no son válidas.

Answer 15

Proyectos de alto presupuesto: si mantiene sus datos actualizados en la memoria y guarda los cambios en el disco periódicamente, desearía manejar la lógica empresarial aparte del servidor db. caso de uso: servir datos de RAM, mecanismos de almacenamiento en caché complejos.

Proyectos de bajo presupuesto: si mantiene los datos actualizados en el disco y su presentación depende de las lecturas del disco, manejar la lógica empresarial en los procedimientos almacenados puede ahorrarle tiempo de desarrollo. caso de uso: servir datos del disco

Answer 16

Hay diferentes tipos de " lógica de negocios " ;. Considere particionarlo en función de cómo está relacionado con otras capas o servicios. Aquí hay algunas reglas generales desde una perspectiva MVC:

a) En la base de datos (procedimiento almacenado) si está relacionado principalmente con datos, y se puede hacer con uniones y cláusulas WHERE y SELECT relativamente simples.

b) en el controlador si está relacionado principalmente con el enrutamiento o el despacho; es decir, control de flujo de IU a mayor escala en términos de selección de pantalla o recurso.

c) en el modelo o modelo de vista si involucra cálculos complejos o complejos y / o condicionales.

d) En la vista (como Razor) si se trata principalmente de un problema de visualización, como " amigable " reformateado y relativamente simple de implementar. (Si es complejo, considere colocarlo en un modelo de vista).

Answer 17

Mi regla general (una vez que reconocí lo que era al pensar en la pregunta) es que los procedimientos almacenados deben contener un código que garantice la integridad de los datos dentro de la base de datos, ya sea que el procedimiento almacenado prohíba la inserción, eliminación o modificación de ciertos datos, o realice otros cambios necesarios para la consistencia de los datos. La lógica empresarial, especialmente la lógica que no puede implementarse en un puñado de operaciones basadas en conjuntos, debe implementarse en otro lugar. Las bases de datos no son aplicaciones. Las bases de datos deberían ser la máxima autoridad para las relaciones y restricciones, incluso si las reglas de negocio también se implementan en otros lugares para, por ejemplo, proporcionar comentarios en el código de la interfaz de usuario que reduce las devoluciones de datos de un servidor web o elimina los golpes innecesarios en un servidor ocupado. Se puede argumentar si & Quot; consistencia de datos & Quot; incluye el resultado del procesamiento complejo de reglas comerciales complejas, pero creo que generalmente está claro una vez que se comprende el contexto. No todas las reglas de negocio se implementan como relaciones de datos o restricciones. No todas las operaciones en un procedimiento almacenado son más rápidas que el código que se ejecuta en un proceso separado, incluso en un proceso que se ejecuta en una máquina separada a través de una red. Recientemente hice una demostración que muestra que muchas operaciones en SSIS, por ejemplo, (INSERTAR EN (SELECCIONAR DESDE)) funcionan más rápido en SSIS que se ejecuta en una red en una máquina separada que en un procedimiento almacenado (que también inserta los resultados en una base de datos a través de la red). Este es un resultado casi increíble (donde SSIS es más rápido que las declaraciones SQL sin procesar), y demuestra que el descubrimiento de la mejor optimización de cualquier problema de rendimiento proviene de la realidad (prueba) y no de la lógica basada en solo unos pocos conceptos. (Todavía tenemos que tomar decisiones sobre qué probar según las reglas generales aprendidas por la experiencia). (SSIS funcionó más rápido implementando automáticamente subprocesos múltiples y canalizaciones, utilizando BULK INSERT incluso donde no se especificó en la instrucción SQL sin formato y enviando lotes de inserciones en un subproceso mientras se crean INSERTOS A GRANEL adicionales en otros subprocesos. En este caso, se realizó aproximadamente el doble de rápido que las declaraciones SQL sin procesar.) Cuando solía enseñar programación y cursos de SQL Server, los usuarios de PowerBuilder parecían tener la declaración quot; Los controladores nativos proporcionan el acceso de datos más rápido " quemado en su lengua, y si bien podría justificarse mediante una explicación adicional (no reconocida por ellos), el pensamiento detrás de esto es engañoso.