database - software - tier server

Lógica empresarial en la base de datos versus el código? (16)

Como ingeniero de software, tengo un fuerte sesgo hacia la escritura de lógica de negocios en la capa de aplicación, mientras que normalmente confío en la base de datos para poco más que las operaciones CRUD (Crear Recuperar Actualización y Eliminar). Por otro lado, me encontré con aplicaciones (generalmente más antiguas) donde una gran cantidad de la lógica de negocio se escribía en procedimientos almacenados, por lo que hay personas que prefieren escribir lógica comercial en la capa de la base de datos.

Para las personas que tienen y / o disfrutan la lógica de negocios escrita / escrita en un procedimiento almacenado, ¿cuáles fueron / son sus razones para usar este método?

A menudo se encuentra lógica de negocios en la capa de la base de datos porque a menudo puede ser más rápido hacer un cambio e implementar. Creo que a menudo las mejores intenciones son no poner la lógica allí, pero debido a la facilidad de implementación, termina allí.

A veces, la lógica empresarial es demasiado lenta para ejecutarse en la capa de la aplicación. Esto es especialmente cierto en sistemas más antiguos donde la potencia del cliente y el ancho de banda eran más limitados.

Creo que especialmente para aplicaciones antiguas en las que estoy trabajando (Banca) donde la lógica de Bussiness es enorme, es casi imposible realizar toda esta lógica empresarial en la capa de aplicación, y también es un gran logro cuando ponemos esta lógica en la capa de Aplicación donde el número de búsquedas en la base de datos es mayor, resulta en una mayor utilización de los recursos (más objetos Java si se hace en la capa Java) y problemas de red y olvídate de su rendimiento.

Dos buenas razones para poner la lógica comercial en la base de datos son:

Asegura su lógica y datos contra aplicaciones adicionales que pueden acceder a la base de datos que no implementan una lógica similar.
Los diseños de las bases de datos generalmente sobreviven a la capa de aplicación y reducen el trabajo necesario cuando se pasa a las nuevas tecnologías en el lado del cliente.

En la medida de lo posible, mantenga su lógica comercial en el entorno que sea más comprobable y depurable . Existen algunas razones válidas para almacenar la lógica de negocios en la base de datos en las respuestas existentes de otras personas, pero casi siempre se ven superadas por esto.

En un par de ocasiones puse la ''lógica'' en venta porque la CRUD podría estar sucediendo en más de un lugar. Por ''lógica'' tendría que decir que no es realmente lógica empresarial sino más ''lógica de integridad''. Podría ser lo mismo: podría ser necesaria cierta limpieza si algo se borra o se actualiza de cierta manera, y si esa eliminación o actualización podría ocurrir a partir de más de una herramienta con diferentes bases de código, tenía sentido ponerlo en el proceso que todo usado.

Además, a veces la ''línea lógica de negocios'' es bastante borrosa. Tomemos informes, por ejemplo: pueden confiar en procedimientos almacenados o vistas que encapsulan ''inteligencia'' sobre lo que el esquema significa para la empresa. ¿Con qué frecuencia ha visto declaraciones CASE y cosas por el estilo que ''hacen cosas'' basadas en valores de columnas u otras críticas? Podría interpretarse como lógica de negocios y, sin embargo, probablemente pertenezca a la base de datos donde pueda optimizarse, etc.

Estoy en un equipo para crear y mantener un sistema financiero bastante grande, y no encuentro manera de poner la lógica en la capa de aplicación para la acción que afecta u obtiene restricciones de docenas de miles de registros.

Además del problema de rendimiento, si ocurren errores, rectificar los procedimientos almacenados es mucho más rápido que depurar la aplicación, arreglar, recompilar, volver a implementar el código con un tiempo de inactividad más prolongado.

Hacemos un montón de procesamiento en el nivel de DB, según corresponda. Hay muchas operaciones en las que no le gustaría retirar grandes conjuntos de datos al nivel de aplicación para realizar análisis. También es una implementación más fácil para nosotros: un punto único frente a la actualización de aplicaciones en todos los puntos de instalación. Pero mucho depende de tu aplicación y de lo que haga; no hay una sola buena respuesta aquí.

Intento limitar seriamente mi lógica comercial en el DB a solo los procesos que tienen que hacer muchas consultas y actualizaciones para realizar una sola operación de aplicación. Algunos pueden argumentar que incluso eso debería estar en la aplicación, pero me gusta mantener el IO abajo si puedo.

Las bases de datos son geniales para CRUD, pero si se llenan de lógica:

Se vuelve confuso dónde está la lógica,
Normalmente, las bases de datos son un silo y no se escalan horizontalmente casi tan bien como los servidores de aplicaciones.
t_sql / PLsql es difícil de leer y de naturaleza procesal
Pierdes todos los beneficios de OOAD.

La razón principal para usar la base de datos para hacer el trabajo es que tiene un único punto de control. A menudo, los desarrolladores de aplicaciones reutilizan o reescriben fragmentos de código en diferentes partes de la aplicación. Incluso suponiendo que todo esto funciona exactamente de la misma manera (lo cual es dudoso), cuando la lógica de negocios cambia, la aplicación necesita ser revisada, recodificada, recompilada. A menos que los parámetros cambien, esto no sería necesario cuando la lógica comercial esté almacenada solo en la base de datos.

La razón principal por la que pondría BL en los procesos almacenados en el pasado es que las transacciones fueron más fáciles en la base de datos.

Si las implementaciones son difíciles para su aplicación y no tiene un servidor de aplicaciones, cambiar la BL en procedimientos almacenados es la forma más efectiva de implementar un cambio.

Limitar la lógica de negocios a la capa de aplicación es, en el mejor de los casos, corto de miras. Los diseñadores experimentados de bases de datos profesionales rara vez lo permiten en sus sistemas. La base de datos necesita tener restricciones, desencadenantes y procesos almacenados para ayudar a definir cómo los datos de cualquier fuente entrarán en ella.

Si la base de datos debe mantener su integridad y garantizar que todas las fuentes de datos nuevos o cambios de datos sigan las reglas, la base de datos es el lugar para poner la lógica requerida. Ponerlo en la capa de aplicación es una pesadilla de datos a punto de suceder. Las bases de datos no obtienen información solo desde una aplicación. Las importaciones importan involuntariamente la lógica empresarial en la aplicación (suponiendo que tiene un cliente nuevo que quiere que se importen sus datos históricos anteriores a su sistema o una gran cantidad de registros de destino, nadie va a ingresar un millón de posibles destinos a través de la interfaz, sucederá en una importación.) También se pasa por alto por los cambios realizados a través de la ventana de consulta para corregir problemas de una sola vez (cosas como aumentar el precio de todos los productos en un 10%). Si tiene una lógica de capa de aplicación que debería haberse aplicado al cambio de datos, no será así. Ahora está bien ponerlo también en la capa de aplicación, no tiene sentido enviar datos erróneos a la base de datos y desperdiciar ancho de banda de la red, pero no colocarlo en la base de datos tarde o temprano causará problemas de datos.

Otra razón para mantener todo esto en la base de datos tiene que ver con la posibilidad de que los usuarios cometan fraudes. Si coloca toda su lógica en la capa de la aplicación, debe otorgar a los usuarios acceso directo a las tablas. Si encapsula toda su lógica en los procesos almacenados, se pueden limitar a hacer solo lo que permiten los procesos almacenados y nada más. No consideraría permitir ningún tipo de acceso de usuarios a una base de datos que almacene registros financieros o información personal (como registros de salud) ya que no permitiría que nadie, excepto un par de dbas, acceda directamente a los registros de producción de ninguna forma o forma . Se cometen más fraudes de lo que muchos desarrolladores se dan cuenta y casi ninguno de ellos considera la posibilidad en su diseño.

Si necesita importar una gran cantidad de datos, pasar por una capa de acceso a datos podría ralentizar la importación a un rastreo, ya que no aprovecha las operaciones basadas en conjuntos que las bases de datos están diseñadas para manejar.

Mi preferencia es mantener cualquier lógica comercial complicada fuera de la base de datos, simplemente por cuestiones de mantenimiento. Si recibo una llamada a las 2 en punto de la mañana, prefiero depurar el código de mi aplicación antes que intentar pasar por las secuencias de comandos de la base de datos.

Su uso del término "lógica de negocios" es bastante vago.

Se puede interpretar que significa incluir la aplicación de restricciones en los datos (también conocidas como ''reglas de negocios''). La aplicación de estos inequívocamente pertenece en el DBMS, punto.

También se puede interpretar que significa incluir cosas como "si llega un nuevo cliente, luego dentro de una semana le enviaremos una carta de bienvenida". Intentar empujar cosas como esta en la capa de datos es probablemente un gran error. En tales casos, el controlador para "crear una nueva carta de bienvenida" probablemente sea la aplicación que también active la nueva inserción de filas del cliente. Imagine cada nueva inserción de filas de bases de datos activando una nueva carta de bienvenida, y de repente tomamos otra compañía y debemos integrar a los clientes de esa compañía en nuestra propia base de datos ... Ouch.

Trabajo para una empresa de tipo financiero donde los estados aplican ciertas reglas, y estas reglas y sus cálculos están sujetos a cambios casi a diario, si no seguramente semanalmente. Siendo ese el caso, tenía más sentido mover partes de la lógica que trata sobre cálculos a la base de datos; donde un cambio puede ser probado y aplicado sin tener que recompilar y redistribuir una aplicación, lo cual es imposible de hacer diariamente sin interrumpir el negocio. El proceso almacenado se prueba, se aprueba, se aplica y el usuario final no es más inteligente. Con el cambio a aplicaciones basadas en web, la dependencia de mover la lógica a la base de datos es menor, pero aún está presente. Incluso las aplicaciones web (según el idioma) deben compilarse y publicarse en el sitio, lo que podría causar un tiempo de inactividad.

Yo diría que si ''lógica de negocios'' significa flujo de aplicación, control de usuario, operaciones temporizadas y generalmente ''hacer cosas de negocios'', entonces debería estar en la capa de aplicación. Pero si eso significa asegurarse de que no importa cómo cava en los datos, siempre tiene sentido y es un todo sensato, no conflictivo, entonces los controles para hacer cumplir esas reglas van en la DB, absolutamente, sin preguntas. Siempre hay muchas formas de insertar datos en el DB y manipularlos una vez allí. No todas estas formas tienen ''lógica de negocios'' incorporada. Encontrará una sesión de SQL en un DB a través de una ventana de DOS en una llamada de soporte a las 3am. ¡Es muy liberal en lo que permite, por ejemplo! Si la lógica no está en el DB para asegurarse de que TODOS los cambios en los datos tengan sentido, puede asegurarse de que los datos se vuelvan muy, muy complicados con el tiempo. Y dado que un sistema es tan valioso como los datos que posee, eso genera un retorno de la inversión mucho más bajo.