¿Cuáles son los argumentos en contra o para poner la lógica de la aplicación en la capa de la base de datos?

NOTA La audiencia de programmers.se y dba.se es diferente y tendrá diferentes puntos de vista, por lo que en este caso creo que es válido duplicar ¿Cuáles son los argumentos en contra o para poner la lógica de la aplicación en la capa de la base de datos? en programmers.se.

No pude encontrar discusión sobre dba sobre esto, y la publicación original lo dice todo, así que:

La mayoría de los desarrolladores de software quieren mantener la lógica de la aplicación en la capa de aplicación, y probablemente nos parezca natural mantenerla aquí. Los desarrolladores de bases de datos parecen querer poner la lógica de la aplicación en la capa de la base de datos, como disparadores y procedimientos almacenados.

Personalmente, preferiría mantener la mayor cantidad posible en la capa de aplicación para facilitar la depuración y mantener separadas las responsabilidades de las capas.

¿Qué piensa sobre esto y qué debería o no debería implementarse en la capa de base de datos?

Nota: no soy el OP para esa pregunta, pero dejé la redacción original intacta.

Pensamientos variados ...

El código de su base de datos sobrevivirá a la tecnología de su cliente de aplicación. Piense en ADO.NET -> Linq -> EF, así como en varios ORM. Mientras que aún puede ejecutar el código SQL Server 2000 del último milenio en todas las tecnologías cliente anteriores.

También tiene el problema de varios clientes: tengo .net, java y Excel. Eso es 3 conjuntos de lógica de aplicación.

La "lógica empresarial" no debe confundirse con la "lógica de integridad de datos". Si tiene clientes que inician transacciones y realizan una variedad de cheques, son muchas llamadas db y una transacción larga.

La lógica de la aplicación no escala para grandes volúmenes de datos. Tenemos 50k filas por segundo usando procs almacenados. Un equipo hermano que usa Hibernate no puede obtener uno por segundo

Quiero toda la lógica que debe aplicarse a todos los usuarios y todas las aplicaciones en la base de datos. Ese es el único lugar sano para ponerlo.

El último Fortune 500 en el que trabajé tenía aplicaciones escritas en al menos 25 idiomas que llegaban a su base de datos OLTP. Algunos de esos programas pasaron a producción en la década de 1970.

La alternativa a la implementación de este tipo de requisitos en la base de datos es permitir que cada programador de aplicaciones vuelva a implementar todo o parte de ella al 100% correctamente, cada vez que encienden su editor, desde el día en que entran por la puerta hasta que la empresa deja de funcionar. negocio.

¿Cuáles son las probabilidades?

¿No es este el mayor " no te repitas " en el planeta?

Estoy moviendo mi respuesta anterior sin editar de programmers.se, ya que las respuestas parecen bastante polarizadas entre sitios.

Sé que estoy en un mundo de dolor aquí, pero puse la lógica de negocios en la base de datos porque:

• Puede permitir a los usuarios avanzados de negocios el acceso directo a la base de datos y no preocuparse de que la arruinen (o preocuparse menos de lo que lo haría con la lógica basada en aplicaciones)
• Un usuario avanzado puede crear nuevos informes sin esperar una nueva versión de software.
• Puede probar el código SP / TRIGGER en una copia de la base de datos, al igual que prueba la lógica basada en aplicaciones
• Puede mantener el SQL para crear sp y desencadenantes en archivos de texto (debe hacer esto de todos modos para el código de tabla / vista)
• Puede mezclar y combinar idiomas sin portar lógica empresarial
• Puede realizar cambios en la lógica empresarial sin actualizar cada bit de software
• Usted audita los cambios en la estructura de la misma manera que audita la actividad de la base de datos: a través del registro
• Seguridad mejorada y control de acceso de grano fino (la mayoría de las implementaciones lógicas basadas en aplicaciones usan su propio modelo de seguridad, por lo que los datos son mucho más fáciles de comprometer. El cifrado de contraseña reversible no es infrecuente)
• La seguridad del usuario en el lado de la base de datos reduce en gran medida el daño / robo que SQL puede hacer

Las desventajas son: - Los desarrolladores amenazados cuando los usuarios se vuelven menos dependientes de los desarrolladores para los informes personalizados - Los desarrolladores necesitan aprender otro lenguaje de programación

Ninguno de esos debe ser importante para un desarrollador experto.

Es interesante notar que la mayoría de las respuestas hablan en términos de 'lógica de aplicación', no 'lógica de negocios', como si el software no estuviera allí para proporcionar una función de negocios.

El problema más importante es si alguna 'capa' sobre la base de datos cree que posee los datos. La concurrencia y la integridad de los datos son problemas para los cuales la solución es un RDBMS: algunas aplicaciones se desarrollan como si la base de datos fuera solo su cubo de bits personal y, por supuesto, terminan intentando reinventar la rueda de muchas maneras, así como ser irreparablemente roto tan pronto como alguna otra aplicación acceda a la misma base de datos

Escribí mi respuesta a esto en mi blog . Mi conclusión es que hacerlo en la aplicación simplemente no se escala una vez que se considera todo el ciclo de vida de la aplicación.

...
3. Agregue restricciones de integridad / verificación a la base de datos subyacente,con código más complejo implementado en el lenguaje de procedimiento almacenado de la base de datos. ¡De esto obtenemos una ubicación central para mantener y obtenemos una aplicación absoluta de las reglas incluso para aplicaciones que no conocemos! Obtenemos un idioma para expresar las reglas de negocio, a lo largo de todo el portafolio de aplicaciones y el ciclo de vida, ya que el idioma del día cambia con mucha más frecuencia que la base de datos. Y se ejecuta en un sistema que ya es tan crítico como las aplicaciones más importantes. Los errores son manejados por el código existente que maneja los errores de la base de datos en esas aplicaciones. Todavía existe el riesgo de que una aplicación se rompa, por supuesto, pero de los tres escenarios, este es el menor, y solo la aplicación rota necesita alguna modificación, no todos (y la mayoría de los mecanismos de SP / base de datos permitirán hacer una excepción para una aplicación si eso es realmente, realmente necesario). ¿Crees que esto no importa en tu sitio greenfield o pequeña empresa? Bueno, si su negocio tiene éxito, en 30 años deseará haber prestado atención a mi sabiduría.

... Algunas [objeciones] a menudo escucho:

• Es difícil controlar el código SP de la versión implementado en la base de datos. No creo que sea más cierto que decir que es difícil controlar el código de Java implementado en un servidor de aplicaciones, es decir, no es difícil en absoluto, es común. Y en Ruby-land, se escriben libros enteros sobre cómo llevar su código de un entorno de desarrollo a producción, algo con lo que ninguna otra comunidad lingüística parece tener problemas. Sin embargo, la versión que controla un procedimiento almacenado es aparentemente demasiado difícil.
• Los procedimientos almacenados son difíciles de probar. Esta es una extraña. Para empezar, los SP están fuertemente tipados; el compilador le dirá si hay una ruta de entrada o salida de código que no tiene sentido y, al menos en Oracle, calculará todas las dependencias por usted. Así que ese es un conjunto de pruebas de unidades comunes que podrías necesitar en Ruby eliminado del bate. Para probar el código OO es necesario burlarse para obligar al objeto al estado interno requerido para representar el escenario de prueba: ¿en qué se diferencia la configuración de los datos de prueba? Hay un productor de TAP para PL / SQL y otras herramientas además. También hay depuradores y perfiladores.
• Un lenguaje de procedimiento almacenado no es un lenguaje con todas las funciones. Bueno, ¡no estamos tratando de escribir una aplicación completa solo en procedimientos almacenados! La mayoría de los lenguajes SP dedicados tienen todas las construcciones modernas que cabría esperar, y al menos en Oracle, puede usar los procedimientos almacenados de Java con todas las características del lenguaje con las que los desarrolladores de OO están familiarizados, o los procedimientos externos en cualquier idioma. Lo que importa es dónde se implementa la lógica, en un lugar, cerca de los datos, el lenguaje real es solo un detalle. PL / SQL se compila en código nativo y se ejecuta en proceso con la base de datos; no hay arquitectura de mayor rendimiento que eso.
• No quiero tener que aprender otro idioma. Pasando por alto por un segundo, esta es una gran señal de alerta en cualquier desarrollador (especialmente uno que propone modificar aplicaciones de producción que podrían estar en otros idiomas de todos modos). Hay mucho que aprender a trabajar en cualquier entorno moderno: una tienda típica de Java podría tener Eclipse , WebLogic, Maven, Hudson, Anthill, Subversion y una gran cantidad de otros, que debe aprender antes de escribir una sola línea de código de aplicación. Un conocimiento práctico de un lenguaje SP de muy alto nivel es sencillo en comparación, y es muy probable que haya un especialista o un DBA para ayudarlo también. Sin mencionar que el desarrollador favorito de Hibernate viene con su propio lenguaje de consulta ...

...

¿El SQL hace cosas como establecer la lógica y el filtrado de resultados orientado a la aplicación? SQL es un maravilloso lenguaje de manipulación de conjuntos.

Además, como GBN señaló anteriormente, el código SQL va a sobrevivir casi universalmente al código de la aplicación.

Si bien es cierto que EF o NHibernate o LinqToSql o lo que sea le permitirá generar código más rápido, cada programador que valga su rendimiento sabe que solo optimizar el SQL optimizará la recuperación de datos. El RDBMS solo comprende SQL, por lo que debe convertir todo en SQL antes de que todo esté dicho y hecho. (suponiendo que podamos estar de acuerdo en que TSQL y PLSQL siguen siendo SQL)

Una desventaja que la gente no necesariamente está discutiendo (los profesionales se han agotado aquí) es el costo.

Las CPU en el servidor de la base de datos son con frecuencia las CPU más costosas en cualquier organización al reducir el costo de la licencia de software. Por lo tanto, trasladar la lógica empresarial al nivel de datos es algo que debe hacerse con prudencia, no necesariamente de manera uniforme.

Aquí es donde la reunión de las mentes, es decir, las mentes de los Desarrolladores (DV) y los DBA, debe suceder inevitablemente. Trabajar con Business Logic (BL) y almacenarlos en una base de datos puede tener un impacto que puede glorificar u horrorizar su implementación.

Para algunos productos RDBMS, existen bibliotecas / herramientas / API superiores para la lógica de negocios y las infraestructuras de objetos que uno podría aprender y emplear rápidamente en sus aplicaciones. Para otros RDBMS, no existen bibliotecas / herramientas / API.

En el pasado, las aplicaciones del servidor cliente hicieron el puente en BL a través de Procedimientos almacenados (SP). Para productos como Oracle y SQL Server, esto se hizo temprano. A medida que surgieron bases de datos de código abierto como PostgreSQL y MySQL, quienes las usaban corrían el riesgo de abrir nuevos caminos con los procedimientos almacenados en BL. PostgreSQL maduró muy rápidamente en esto, ya que no solo se implementaron procedimientos almacenados, sino que también surgió la capacidad de crear idiomas para los clientes. MySQL básicamente dejó de evolucionar en el mundo de los procedimientos almacenados y llegó en una forma simplificada de un lenguaje con muchas restricciones. Por lo tanto, cuando se trata de BL, está completamente a merced de MySQL y su lenguaje de procedimiento almacenado.

Realmente solo queda una pregunta: independientemente del RDBMS, ¿BL debería residir total o parcialmente en la base de datos?

Piensa en el desarrollador. Cuando las cosas salen mal en una aplicación, el proceso de depuración hará que el Desarrollador entre y salga de una base de datos para seguir los cambios de datos que pueden o no ser correctos intermitentemente. Es como codificar una aplicación C ++ y llamar al código Assembler en el medio. Tienes que cambiar de código fuente, clases y estructuras a interrupciones, registros y compensaciones ¡¡¡Y VOLVER !!! Esto lleva la depuración a ese mismo nivel.

Los desarrolladores pueden crear un método de alta velocidad para ejecutar BL junto con configuraciones de lenguaje (marcas de compilación para C ++, diferentes configuraciones para PHP / Python, etc.) a través de objetos de negocios ubicados en la memoria en lugar de en una base de datos. Algunos han intentado unir esta ideología para un código de ejecución más rápido en la base de datos escribiendo bibliotecas donde la depuración de procedimientos almacenados y disparadores está bien integrada en la base de datos y parece inutilizable.

Por lo tanto, el desarrollador tiene el desafío de desarrollar, depurar y mantener el código fuente y BL en dos idiomas.

Ahora piense en el DBA. El DBA quiere mantener la base de datos ajustada y tener el mayor significado posible en el ámbito de los procedimientos almacenados. El DBA puede ver BL como algo externo a la base de datos. Sin embargo, cuando SQL solicita los datos necesarios para BL, el SQL debe ser sencillo y medio.

Ahora, para el encuentro de las mentes !!!

El desarrollador codifica SP y utiliza métodos iterativos. DBA mira el SP. DBA determina que una sola instrucción SQL puede reemplazar los métodos iterativos escritos por el desarrollador. El desarrollador ve que la declaración SQL sugerida por el DBA requiere llamar a otro código relacionado con BL o SQL que no sigue los planes de ejecución normales de la declaración SQL.

A la luz de esto, la configuración, el ajuste del rendimiento y la codificación SP se convierten en una función de la profundidad y la intensidad de los datos de BL para la recuperación de datos. Mientras más profundidad e intensidad de datos tenga el BL, más Desarrolladores y DBA deben estar en la misma página para la cantidad de datos y poder de procesamiento dado a la Base de Datos.

CONCLUSIÓN

La forma de recuperación de datos siempre debe involucrar a los campamentos de desarrolladores y DBA. Siempre se deben hacer concesiones sobre qué métodos de codificación y paradigmas de recuperación de datos pueden trabajar juntos, tanto para la velocidad como para la eficiencia. Si la preparación de datos para que los maneje el código fuente se realiza solo una vez antes de que el código obtenga los datos, el DBA debe dictar el uso del SQL magro y medio. Si el BL es algo con lo que el DBA no está en sintonía, las riendas están en manos del desarrollador. Esta es la razón por la cual el DBA debe verse a sí mismo y formar parte del equipo del proyecto y no una isla en sí mismo, mientras que el Desarrollador debe permitir que DBA realice el ajuste fino del SQL si lo justifica.

Es una buena pregunta para hacer en un sitio web lleno de DBA. Con suerte, la mayoría de las respuestas serán "pro" para mantener la base de datos en un estado ACID, y así mantener la lógica de negocios en la base de datos. :-)

En cuanto a mi opinión, creo que debería implementar la lógica empresarial tanto en sus aplicaciones como en sus bases de datos. Este enfoque costará más tiempo y dinero, pero creo que como resultado tendrá una mejor solución comercial cualitativa.

Como Adam Musch dijo anteriormente, hay más que considerar aquí para el rendimiento. Uso de CPU. Uso de memoria.

Obviamente, impide que cosas incorrectas lleguen a la base de datos.

• Elimine las direcciones de correo electrónico que no se ajusten de alguna manera básica.
• Comprobar longitudes

Cuando profundizas es cuando es necesario tomar decisiones. El servidor DB es un lugar muy costoso para hacer cosas que el cliente podría hacer fácilmente. ejemplo: formato de datos, fechas de formato, cadenas de ensamblaje, etc. lado del cliente.

¿Hace los cálculos / procesamiento en el cliente o en el servidor DB? Para mí eso depende de la complejidad y la cantidad de registros involucrados. La lógica de negocios realmente debe hacerse en la base de datos para que todo se trate de la misma manera.
Realmente debería crear una API de vistas para leer y almacenar los procesos para escribir los datos en la base de datos para evitar dolores de cabeza en el futuro.

Use las fortalezas de cada extremo para su beneficio.