Lógica de negocios:Capa de base de datos o aplicación

https://stackoverflow.com/questions/119540

02-07-2019
|

Pregunta

La vieja pregunta.¿Dónde debería colocar su lógica de negocios, en la base de datos como procedimientos almacenados (o paquetes), o en la aplicación/nivel medio?Y lo más importante ¿Por qué?

Suponga que la independencia de la base de datos no es un objetivo.

Solución

Coloque suficiente lógica empresarial en la base de datos para garantizar que los datos sean coherentes y correctos.

Pero no temas tener que duplicar parte de esta lógica en otro nivel para mejorar la experiencia del usuario.

Otros consejos

La capacidad de mantenimiento de su código es siempre una gran preocupación a la hora de determinar dónde debe ir la lógica empresarial.

Las herramientas de depuración integradas y los IDE más potentes generalmente hacen que mantener el código de nivel medio sea más fácil que el mismo código en un procedimiento almacenado.A menos que exista una razón real para lo contrario, debe comenzar con la lógica empresarial en su nivel/aplicación intermedia y no en los procedimientos almacenados.

Sin embargo, cuando se trata de informes y extracción/búsqueda de datos, los procedimientos almacenados suelen ser una mejor opción.Esto se debe al poder de las capacidades de agregación/filtrado de las bases de datos y al hecho de que se mantiene el procesamiento muy cerca de la fuente de los datos.Pero puede que esto no sea lo que la mayoría considera la lógica empresarial clásica.

Para casos muy simples, puede poner su lógica empresarial en procedimientos almacenados.Por lo general, incluso los casos simples tienden a complicarse con el tiempo.Estas son las razones por las que no incluyo lógica empresarial en la base de datos:

Poner la lógica empresarial en la base de datos la vincula estrechamente con la implementación técnica de la base de datos.Cambiar una tabla hará que cambie muchos de los procedimientos almacenados nuevamente, lo que provocará muchos errores adicionales y pruebas adicionales.

Por lo general, la interfaz de usuario depende de la lógica empresarial para cosas como la validación.Poner estas cosas en la base de datos provocará un estrecho acoplamiento entre la base de datos y la interfaz de usuario o, en diferentes casos, duplicará la lógica de validación entre esas dos.

Será difícil que varias aplicaciones funcionen en la misma base de datos.Los cambios en una aplicación provocarán que otras no funcionen.Esto puede convertirse rápidamente en una pesadilla de mantenimiento.Entonces realmente no escala.

En términos más prácticos, SQL no es un buen lenguaje para implementar la lógica empresarial de una manera comprensible.SQL es excelente para operaciones basadas en conjuntos, pero omite construcciones para "programación en grande", es difícil mantener grandes cantidades de procedimientos almacenados.Los lenguajes orientados a objetos modernos son más adecuados y más flexibles para esto.

Esto no significa que no pueda utilizar vistas y procesos almacenados.Creo que a veces es una buena idea poner una capa adicional de procedimientos almacenados y vistas entre las tablas y las aplicaciones para desacoplarlas.De esa manera, puede cambiar el diseño de la base de datos sin cambiar la interfaz externa, lo que le permitirá refactorizar la base de datos de forma independiente.

Realmente depende de ti, mientras seas consistente.

Una buena razón para ponerlo en la capa de su base de datos:si está bastante seguro de que sus clientes nunca cambiarán el back-end de su base de datos.

Una buena razón para ponerlo en la capa de aplicación:si está apuntando a múltiples tecnologías de persistencia para su aplicación.

También debes tener en cuenta las competencias básicas.¿Sus desarrolladores son principalmente desarrolladores de la capa de aplicaciones o son principalmente del tipo DBA?

Si bien ciertamente existen beneficios al tener la lógica empresarial en la capa de aplicación, me gustaría señalar que los lenguajes/marcos parecen cambiar con más frecuencia que las bases de datos.

Algunos de los sistemas que apoyo pasaron por las siguientes UI en los últimos 10 a 15 años:Formularios Oracle/Visual Basic/Perl CGI/ASP/Java Servlet.Lo único que no cambió: la base de datos relacional y los procedimientos almacenados.

Si bien no existe una respuesta correcta (depende del proyecto en cuestión), recomendaría el enfoque recomendado en "Diseño basado en dominion" de Eric Evans.En este enfoque, la lógica empresarial está aislada en su propia capa, la capa de dominio, que se encuentra encima de las capas de infraestructura, que podrían incluir el código de su base de datos, y debajo de la capa de aplicación, que envía las solicitudes a la capa de dominio. para su cumplimiento y escucha la confirmación de su finalización, impulsando eficazmente la aplicación.

De esta manera, la lógica de negocios se captura en un modelo que puede discutirse con quienes entienden el negocio más allá de las cuestiones técnicas, y debería facilitar el aislamiento de los cambios en las reglas de negocio mismas, los problemas de implementación técnica y el flujo de trabajo. la aplicación que interactúa con el modelo de negocio (dominio).

Recomiendo leer el libro anterior si tiene la oportunidad, ya que es bastante bueno para explicar cómo este ideal puro puede aproximarse en el mundo real del código y los proyectos reales.

La independencia de la base de datos, que el interrogador descarta como consideración en este caso, es el argumento más fuerte para eliminar la lógica de la base de datos.El argumento más fuerte a favor de la independencia de la base de datos es la capacidad de vender software a empresas con su propia preferencia por un backend de base de datos.

Por lo tanto, consideraría que el argumento principal para eliminar los procedimientos almacenados de la base de datos es sólo comercial, no técnico.Puede haber razones técnicas, pero también hay razones técnicas para mantenerlo ahí: rendimiento, integridad y la capacidad de permitir que múltiples aplicaciones usen la misma API, por ejemplo.

El uso o no de SP también está fuertemente influenciado por la base de datos que vaya a utilizar.Si no tiene en cuenta la independencia de la base de datos, tendrá experiencias muy diferentes al utilizar T-SQL o PL/SQL.

Si está utilizando Oracle para desarrollar una aplicación, entonces PL/SQL es una opción obvia como lenguaje.Está muy estrechamente vinculado con los datos, se mejora continuamente en cada versión, y cualquier herramienta de desarrollo decente integrará el desarrollo PL/SQL con CVS o Subversion o algo así.

El entorno de desarrollo Application Express basado en web de Oracle incluso está construido 100% con PL/SQL.

Todo lo que afecte la integridad de los datos debe colocarse a nivel de base de datos.Otras cosas además de la interfaz de usuario a menudo colocan, actualizan o eliminan datos de la base de datos, incluidas importaciones, actualizaciones masivas para cambiar un esquema de precios, correcciones urgentes, etc.Si necesita asegurarse de que siempre se sigan las reglas, coloque la lógica en valores predeterminados y activadores.

Esto no quiere decir que no sea una buena idea tenerlo también en la interfaz de usuario (para qué molestarse en enviar información que la base de datos no aceptará), pero ignorar estas cosas en la base de datos es arriesgarse al desastre.

Si necesita independencia de la base de datos, probablemente desee colocar toda su lógica de negocios en la capa de aplicación, ya que los estándares disponibles en la capa de aplicación son mucho más frecuentes que los disponibles en la capa de base de datos.

Sin embargo, si la independencia de la base de datos no es el factor número uno y el conjunto de habilidades de su equipo incluye sólidas habilidades en bases de datos, entonces poner la lógica de negocios en la base de datos puede resultar ser la mejor solución.Puede hacer que la gente de su aplicación haga cosas específicas de la aplicación y la gente de su base de datos se asegure de que todas las consultas funcionen.

Por supuesto, hay una gran diferencia entre poder generar una declaración SQL y tener "sólidas habilidades en bases de datos". Si su equipo está más cerca de lo primero que de lo segundo, entonces coloque la lógica en la aplicación usando uno de los Hibernates de este mundo. (¡o cambia de equipo!).

Según mi experiencia, en un entorno empresarial tendrá una única base de datos de destino y habilidades en esta área; en este caso, coloque todo lo que pueda en la base de datos.Si se dedica a vender software, los costos de la licencia de la base de datos harán que la independencia de la base de datos sea el factor más importante y usted implementará todo lo que pueda en el nivel de aplicación.

Espero que ayude.

Hoy en día es posible enviar a subversión su código de proceso almacenado y depurarlo con una buena herramienta de soporte.

Si utiliza procesos almacenados que combinan declaraciones SQL, puede reducir la cantidad de tráfico de datos entre la aplicación y la base de datos, reducir la cantidad de llamadas a la base de datos y obtener grandes ganancias de rendimiento.

Una vez que comenzamos a compilar en C#, tomamos la decisión de no usar procesos almacenados, pero ahora estamos moviendo cada vez más código a procesos almacenados.Especialmente procesamiento por lotes.

Sin embargo, no utilice desencadenantes, utilice procesos almacenados o mejores paquetes.Los desencadenantes disminuyen la mantenibilidad.

Poner el código en la capa de aplicación dará como resultado una aplicación independiente de la base de datos.

A veces es mejor utilizar procedimientos almacenados por motivos de rendimiento.

Depende (como siempre) de los requisitos de la aplicación.

Lo único que va en una base de datos son los datos.

Los procedimientos almacenados son una pesadilla de mantenimiento.No son datos y no pertenecen a la base de datos.La interminable coordinación entre desarrolladores y DBA es poco más que fricción organizacional.

Es difícil mantener un buen control de versiones de los procedimientos almacenados.El código fuera de la base de datos es realmente fácil de instalar: cuando cree que tiene la versión incorrecta, simplemente realiza un SVN UP (tal vez una instalación) y su aplicación vuelve a un estado conocido.Tiene variables de entorno, enlaces de directorios y mucho control ambiental sobre la aplicación.

Puedes, con simples PATH manipulaciones, tener software variante disponible para diferentes situaciones (formación, pruebas, control de calidad, producción, mejoras específicas del cliente, etc., etc.)

Sin embargo, el código dentro de la base de datos es mucho más difícil de gestionar.No existe un entorno adecuado (ni "RUTA", enlaces de directorio u otras variables de entorno) que proporcione un control utilizable sobre el software que se está utilizando;tiene un conjunto permanente y global de software de aplicación atrapado en la base de datos, unido a los datos.

Los desencadenantes son aún peores.Son tanto una pesadilla de mantenimiento como de depuración.No veo qué problema resuelven;parecen ser una forma de solucionar aplicaciones mal diseñadas en las que alguien no se molesta en utilizar las clases disponibles (o bibliotecas de funciones) correctamente.

Si bien algunas personas encuentran convincente el argumento del rendimiento, todavía no he visto suficientes datos de referencia para convencerme de que los procedimientos almacenados son tan rápidos.Todo el mundo tiene una anécdota, pero nadie tiene un código paralelo donde los algoritmos sean más o menos iguales.

[En los ejemplos que he visto, la aplicación antigua era un desastre mal diseñada;cuando se escribieron los procedimientos almacenados, se rediseñó la aplicación.Creo que el cambio de diseño tuvo más impacto que el cambio de plataforma.]

La lógica empresarial debe colocarse en la aplicación/nivel medio como primera opción.De esa manera, puede expresarse en forma de modelo de dominio, colocarse en el control de código fuente, dividirse o combinarse con código relacionado (refactorizado), etc.También le brinda cierta independencia del proveedor de la base de datos.

Los lenguajes orientados a objetos también son mucho más expresivos que los procedimientos almacenados, lo que le permite describir mejor y más fácilmente en el código lo que debería estar sucediendo.

Las únicas buenas razones para colocar código en procedimientos almacenados son:si hacerlo produce un beneficio de rendimiento significativo y necesario o si el mismo código comercial debe ejecutarse en múltiples plataformas (Java, C#, PHP).Incluso cuando se utilizan múltiples plataformas, existen alternativas, como los servicios web, que podrían ser más adecuados para compartir funciones.

Según mi experiencia, la respuesta se encuentra en algún lugar de un espectro de valores generalmente determinado por dónde se encuentran las habilidades de su organización.

El DBMS es una bestia muy poderosa, lo que significa que un tratamiento adecuado o inadecuado traerá grandes beneficios o grandes peligros.Lamentablemente, en demasiadas organizaciones se presta atención primordial al personal de programación;Se descuidan las habilidades de DBMS, especialmente las habilidades de desarrollo de consultas (a diferencia de las administrativas).Lo cual se ve agravado por el hecho de que probablemente también falte la capacidad de evaluar las habilidades de DBMS.

Y hay pocos programadores que comprendan suficientemente lo que no comprenden sobre las bases de datos.

De ahí la popularidad de conceptos subóptimos, como Active Records y LINQ (para incluir algún sesgo obvio).Pero probablemente sean la mejor respuesta para este tipo de organizaciones.

Sin embargo, tenga en cuenta que las organizaciones de gran escala tienden a prestar mucha más atención al uso eficaz del almacén de datos.

No existe una respuesta correcta e independiente a esta pregunta.Depende de los requisitos de tu aplicación, las preferencias y habilidades de tus desarrolladores y la fase de la luna.

La lógica empresarial debe colocarse en el nivel de aplicación y no en la base de datos.La razón es que un procedimiento almacenado de base de datos siempre depende del producto de base de datos que utilice.Esto rompe una de las ventajas del modelo de tres niveles.No puede cambiar fácilmente a otra base de datos a menos que proporcione un procedimiento almacenado adicional para este producto de base de datos.por otro lado, a veces tiene sentido poner lógica en un procedimiento almacenado para optimizar el rendimiento.

Lo que quiero decir es que la lógica empresarial debe colocarse en el nivel de aplicación, pero hay excepciones (principalmente por motivos de rendimiento).

Las 'capas' de aplicaciones empresariales son:

1.Interfaz de usuario

Esto implementa la visión que tiene el usuario empresarial de su trabajo.Utiliza términos con los que el usuario está familiarizado.

2.Procesando

Aquí es donde ocurren los cálculos y la manipulación de datos.Aquí se implementa cualquier lógica empresarial que implique cambiar datos.

3.Base de datos

Esto podría ser:una base de datos secuencial normalizada (los DBMS estándar basados en SQL);una base de datos OO, que almacena objetos que envuelven los datos comerciales;etc.

¿Qué va? ¿Dónde?

Para llegar a las capas anteriores es necesario realizar el análisis y el diseño necesarios.Esto indicaría dónde se implementaría mejor la lógica empresarial:Las reglas de integridad de datos y los problemas de concurrencia/tiempo real relacionados con las actualizaciones de datos normalmente se implementarían lo más cerca posible de los datos, al igual que los campos calculados, y este es un buen indicador de los procedimientos almacenados/activadores, donde la integridad de los datos y el control de las transacciones es absolutamente necesario.

Las reglas de negocio que involucran el significado y el uso de los datos se implementarían en su mayor parte en la capa de Procesamiento, pero también aparecerían en la Interfaz de Usuario como el flujo de trabajo del usuario, vinculando los diversos procesos en alguna secuencia que refleje el trabajo del usuario.

En mi humilde opinión.Existen dos preocupaciones contradictorias a la hora de decidir dónde va la lógica empresarial en una aplicación basada en bases de datos relacionales:

mantenibilidad
fiabilidad

Re.mantenibilidad:Para permitir un desarrollo futuro eficiente, la lógica empresarial pertenece a la parte de su aplicación que es más fácil de depurar y controlar las versiones.

Re.fiabilidad:Cuando existe un riesgo significativo de inconsistencia, la lógica empresarial pertenece a la capa de base de datos.Las bases de datos relacionales se pueden diseñar para verificar restricciones en los datos, p.no permitir valores NULL en columnas específicas, etc.Cuando surge un escenario en el diseño de su aplicación en el que algunos datos deben estar en un estado específico que es demasiado complejo para expresarlo con estas restricciones simples, puede tener sentido usar un activador o algo similar en la capa de base de datos.

Es difícil mantener los activadores actualizados, especialmente cuando se supone que su aplicación debe ejecutarse en sistemas cliente a los que ni siquiera tiene acceso.Pero eso no significa que sea imposible realizar un seguimiento de ellos o actualizarlos.Los argumentos de S.Lott en su respuesta de que es una molestia y una molestia son completamente válidos, lo apoyaré y también he estado allí.Pero si tiene en cuenta esas limitaciones cuando diseña su capa de datos por primera vez y se abstiene de utilizar activadores y funciones para cualquier cosa que no sean las necesidades absolutas, es manejable.

En nuestra aplicación, la mayor parte de la lógica empresarial está contenida en la capa del modelo de la aplicación, p.una factura sabe cómo inicializarse a partir de un pedido de venta determinado.Cuando se modifican secuencialmente un montón de cosas diferentes para un conjunto complejo de cambios como este, las agrupamos en una transacción para mantener la coherencia, en lugar de optar por un procedimiento almacenado.Cálculo de totales, etc.Todos se hacen con métodos en la capa del modelo.Pero cuando necesitamos desnormalizar algo para mejorar el rendimiento o insertar datos en una tabla de 'cambios' utilizada por todos los clientes para determinar qué objetos deben caducar en su caché de sesión, usamos activadores/funciones en la capa de base de datos para insertar una nueva fila. y enviar una notificación (Postgres escucha/notifica cosas) desde este disparador.

Después de tener nuestra aplicación en el campo durante aproximadamente un año, utilizada por cientos de clientes todos los días, lo único que cambiaría si tuviéramos que empezar desde cero sería diseñar nuestro sistema para crear funciones de base de datos (o procedimientos almacenados, como quiera que se prefiera). desea llamarlos) teniendo en cuenta las versiones y actualizaciones desde el principio.

Afortunadamente, contamos con algún sistema para realizar un seguimiento de las versiones de los esquemas, por lo que creamos algo además de eso para encargarnos de reemplazar las funciones de la base de datos.Sin embargo, nos habría ahorrado algo de tiempo si hubiéramos considerado la necesidad de reemplazarlos desde el principio.

Por supuesto, todo cambia cuando sales del ámbito de los RDBMS y entras en sistemas de almacenamiento de tuplas como Amazon SimpleDB y BigTable de Google.Pero esa es una historia diferente :)

Ponemos mucha lógica de negocios en los procedimientos almacenados; no es lo ideal, pero muy a menudo es un buen equilibrio entre rendimiento y confiabilidad.

¡Y sabemos dónde está sin tener que buscar entre toneladas de soluciones y código base!

La escalabilidad también es un factor muy importante para llevar la lógica empresarial a la capa intermedia o de aplicación en lugar de a la capa de base de datos. Debe entenderse que DatabaseLayer es solo para interactuar con la base de datos, no para manipular cuál se devuelve hacia o desde la base de datos.

Recuerdo haber leído un artículo en alguna parte que señalaba que prácticamente todo puede ser, en algún nivel, parte de la lógica empresarial, por lo que la pregunta no tiene sentido.

Creo que el ejemplo dado fue la visualización de una factura en pantalla.La decisión de marcar en rojo un vencido es una decisión de negocios...

Es un continuo.En mi humilde opinión, el factor más importante es la velocidad.¿Cómo se puede hacer que este tonto esté en funcionamiento lo más rápido posible y al mismo tiempo cumplir con los buenos principios de programación, como mantenibilidad, rendimiento, escalabilidad, seguridad, confiabilidad, etc.?Muchas veces, SQL es la forma más concisa de expresar algo y también resulta ser la de mayor rendimiento muchas veces, excepto para operaciones de cadenas, etc., pero ahí es donde sus CLR Procs pueden ayudar.Mi creencia es distribuir generosamente la lógica empresarial donde crea que es mejor para la empresa en cuestión.Si tiene un grupo de desarrolladores de aplicaciones que se cagan en los pantalones cuando miran SQL, déjeles usar la lógica de su aplicación.Si realmente desea crear una aplicación de alto rendimiento con grandes conjuntos de datos, coloque tanta lógica en la base de datos como pueda.Active sus DBA y brinde a los desarrolladores la máxima libertad sobre sus bases de datos de desarrollo.No existe una única respuesta ni la mejor herramienta para el trabajo.Tiene múltiples herramientas, así que conviértase en un experto en todos los niveles de la aplicación y pronto descubrirá que dedica mucho más tiempo a escribir SQL expresivo, coherente y agradable cuando sea necesario y a utilizar la capa de aplicación en otras ocasiones.Para mí, en última instancia, reducir el número de líneas de código es lo que conduce a la simplicidad.Acabamos de convertir una aplicación rica en SQL con apenas 2500 líneas de código de aplicación y 1000 líneas de SQL a un modelo de dominio que ahora tiene 15500 líneas de código de aplicación y 2500 líneas de SQL para lograr lo que hizo la antigua aplicación rica en SQL.Si puede justificar un aumento de 6 veces en el código como "simplificado", siga adelante.

¡Esta es una gran pregunta!Encontré esto después de haber preguntado algo similar. pregunta, pero esto es más específico.Surgió como resultado de una decisión de cambio de diseño en la que no participé.

Básicamente, lo que me dijeron fue que si tiene millones de filas de datos en las tablas de su base de datos, considere poner la lógica empresarial en los procedimientos almacenados y los activadores.Eso es lo que estamos haciendo ahora, convertir una aplicación Java en procedimientos almacenados para facilitar el mantenimiento, ya que el código Java se ha vuelto complicado.

Encontré este artículo en: Las guerras de la lógica empresarial El autor también hizo el millón de filas en un argumento de tabla, lo cual me pareció interesante.También agregó lógica de negocios en javascript, que está del lado del cliente y fuera del nivel de lógica de negocios.No había pensado en esto antes a pesar de que he usado javascript para la validación durante años, junto con la validación del lado del servidor.

Mi opinión es que desea que la lógica de negocios esté en la aplicación/nivel medio como regla general, pero no descarte los casos en los que tiene sentido ponerla en la base de datos.

Un último punto, hay otro grupo en el que estoy trabajando actualmente que está haciendo un trabajo masivo de bases de datos para investigación y la cantidad de datos con los que están tratando es inmensa.Aún así, para ellos no tienen ninguna lógica de negocios en la base de datos en sí, pero la mantienen en la aplicación/nivel medio.Para su diseño, la aplicación/nivel medio era el lugar correcto para ello, por lo que no usaría el tamaño de las tablas como la única consideración de diseño.

La lógica empresarial suele estar incorporada en objetos y en las diversas construcciones del lenguaje de encapsulación, herencia y polimorfismo.Por ejemplo, si una aplicación bancaria transfiere dinero, puede haber un tipo de Dinero que defina los elementos comerciales de lo que es "dinero".Esto, a diferencia del uso de un decimal primitivo para representar dinero.Por esta razón, la programación orientada a objetos bien diseñada es donde reside la "lógica de negocios", no estrictamente en ninguna capa.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow