¿Cuánta lógica de negocios debe implementar la base de datos?

La lógica de negocios no entra en la base de datos

Si estamos hablando de aplicaciones de múltiples niveles, parece bastante claro que la lógica empresarial, el tipo de inteligencia que ejecuta una empresa en particular, pertenece a la capa de lógica de negocios, no a la capa de acceso a datos.

Las bases de datos hacen algunas cosas realmente bien:

1. Ellos almacenan y recuperan datos
2. Establecen y hacen cumplir las relaciones entre diferentes entidades de datos
3. Proporcionan los medios para consultar los datos en busca de respuestas
4. Proporcionan optimizaciones de rendimiento.
5. Proporcionan control de acceso

Ahora, por supuesto, puede codificar todo tipo de cosas en una base de datos que se relaciona con sus preocupaciones comerciales, como tasas de impuestos, descuentos, códigos de operación, categorías, etc. Pero la acción empresarial que se toma sobre esos datos generalmente no se codifica en la base de datos, por todo tipo de razones ya mencionadas por otros, aunque una acción puede ser elegida en el Base de datos y ejecutado en otro lugar.

Y, por supuesto, puede haber cosas que se realizan en una base de datos por su rendimiento y otras razones:

1. Cierre de un período contable
2. Numeración de cálculos
3. Procesos por lotes nocturnos
4. conmutación por error

Naturalmente, nada está grabado en piedra. Los procedimientos almacenados son adecuados para una amplia gama de tareas simplemente porque viven en el servidor de la base de datos y tienen ciertas fortalezas y ventajas.

Procedimientos almacenados en todas partes

Hay un cierto atractivo en la codificación de todas sus tareas de almacenamiento, administración y recuperación de datos en procedimientos almacenados, y simplemente consumen los servicios de datos resultantes. Sin duda, se beneficiaría de las optimizaciones de seguridad y rendimiento máximas posibles que el servidor de la base de datos podría proporcionar, y eso no es poca cosa.

Pero, ¿a qué te arriesgas?

1. Bloqueo de proveedores
2. La necesidad de desarrolladores con habilidades especiales
3. Herramientas de programación espartanas, en general
4. Acoplamiento de software extremadamente ajustado
5. No hay separación de preocupaciones

Y, por supuesto, si necesitas un servicio web (de todos modos, probablemente sea hacia donde se dirige), todavía tendrás que construirlo.

Entonces, ¿qué es la práctica típica?

Yo diría que un enfoque típico y moderno es usar un Mapeador Relacional de Objetos (como Entity Framework) para crear clases que modelen sus tablas. Luego puede hablar con su base de datos a través de un repositorio que devuelve colecciones de objetos, una situación que es muy familiar para cualquier desarrollador de software competente. El ORM genera dinámicamente el SQL correspondiente a su modelo de datos y la información solicitada, que luego el servidor de la base de datos procesa para devolver los resultados de la consulta.

¿Qué tan bien funciona esto? Muy bien, y mucho más rápido que escribir procedimientos almacenados y vistas. En general, esto cubre aproximadamente el 80% de sus requisitos de acceso a datos, principalmente CRUD. ¿Qué cubre el otro 20%? Lo adivinó: procedimientos almacenados, que todos los principales ORM admiten directamente.

¿Puede escribir un generador de código que haga lo mismo que un ORM, pero con procedimientos almacenados? Seguro que puede. Pero los ORM generalmente son independientes del proveedor, son bien entendidos por todos y están mejor respaldados.

Soy un firme creyente en mantener la lógica empresarial fuera de la base de datos tanto como sea posible. Sin embargo, como desarrollador de rendimiento de mi empresa, aprecio que a veces es necesario lograr un buen rendimiento. Pero creo que es mucho menos necesario de lo que dice la gente.

Disputo tus pros y contras.

Usted afirma que centraliza la lógica de su negocio. Al contrario, creo que lo descentraliza. En un producto en el que trabajo actualmente, usamos procedimientos almacenados para gran parte de nuestra lógica empresarial. Muchos de nuestros problemas de rendimiento provienen de las funciones de llamada repetidamente. Por ejemplo

select <whatever>
from group g
where fn_invoker_has_access_to_group(g.group_id)

El problema con este enfoque es que generalmente (en algunos casos es falso) obliga a la base de datos a ejecutar su función N veces, una vez por fila. A veces esa función es cara. Algunas bases de datos soportan índices de funciones. Pero no puedes indexar cada función posible contra cada entrada posible. ¿O puedes?

Una solución común al problema anterior es extraer la lógica de la función y fusionarla en la consulta. Ahora ha roto la encapsulación y la lógica duplicada.

Otro problema que veo es que llama a los procedimientos almacenados en un bucle porque no hay manera de unir o cruzar conjuntos de resultados de proc almacenados.

declare some_cursor
while some_cursor has rows
    exec some_other_proc
end

Si saca el código del proceso anidado, descentralice nuevamente. Por lo tanto, se ve obligado a elegir entre encapsulación y rendimiento.

En general, encuentro que las bases de datos son malas en:

1. computación
2. Iteración (están optimizados para operaciones de conjuntos)
3. equilibrio de carga
4. análisis

Las bases de datos son buenas en:

1. Bloqueo y desbloqueo
2. Mantener los datos y sus relaciones
3. Asegurar la integridad

Al realizar operaciones costosas como bucles y análisis de cadenas y mantenerlas en el nivel de su aplicación, puede escalar su aplicación horizontalmente para obtener un mejor rendimiento. Por lo general, agregar varios servidores de aplicaciones detrás de un equilibrador de carga es mucho más barato que configurar la replicación de la base de datos.

Sin embargo, está en lo correcto al desacoplar su lógica empresarial del lenguaje de programación de su aplicación, pero no veo por qué es una ventaja. Si tienes una aplicación Java, entonces tienes una aplicación Java. Convertir un montón de código Java en procedimientos almacenados no cambia el hecho de que tienes una aplicación Java.

Mi preferencia es mantener el código de la base de datos enfocado en la persistencia. ¿Cómo se crea un nuevo widget? Debe insertarse en 3 tablas y deben estar en una transacción. Eso pertenece a un procedimiento almacenado.

La definición de lo que se puede hacer con un widget y las reglas comerciales para encontrar widgets pertenecen a su aplicación.

He trabajado en 2 compañías diferentes que tenían una visión diferente sobre el tema.

Mi sugerencia personal sería utilizar procedimientos almacenados cuando el tiempo de ejecución sea importante (rendimiento). Dado que los procedimientos almacenados están compilados, si tiene una lógica compleja para consultar los datos, es mejor mantener eso en la base de datos. Además, solo enviará los datos finales a su programa al final.

De lo contrario, creo que la lógica de un programa debería estar siempre en el software mismo. ¿Por qué? Debido a que un programa debe ser verificable y no creo que haya una manera fácil de probar el procedimiento almacenado por unidad. No olvide que un programa que no se ha probado es un mal programa.

Por lo tanto, use el procedimiento almacenado con precaución cuando sea necesario.

Hay un punto medio que necesitas encontrar. He visto proyectos aterradores en los que los programadores usan la base de datos como nada más que un almacén de valor / clave demasiado caro. He visto otros en los que los programadores no usan claves externas y amp; índices. En el otro extremo del espectro, he visto proyectos en los que la mayoría, si no toda la lógica empresarial, se implementa en el código de la base de datos.

Como ha señalado, T-SQL (o su equivalente en otros RDBMS populares) no es exactamente el mejor lugar para codificar lógica de negocios compleja.

Intento construir un modelo de datos razonablemente decente, uso las características de la base de datos para proteger mis suposiciones acerca de ese modelo (es decir, FK y restricciones), y uso el código de la base de datos con moderación. El código de la base de datos es útil cuando necesita algo (es decir, una suma) que la base de datos es muy buena para hacer y puede evitar que mueva millones de registros a través del cable cuando no los necesite.

Si la lógica de su negocio involucra operaciones de conjuntos, lo más probable es que sea un buen lugar para hacerlo en la base de datos porque los sistemas de bases de datos son realmente buenos para realizar operaciones de conjuntos.

enlace

Si la lógica de negocios implica algún tipo de cálculo, probablemente pertenezca fuera del procedimiento de base de datos / tienda, ya que las bases de datos no están realmente diseñadas para realizar ciclos y cálculos.

Aunque estas no son reglas duras y rápidas, es un buen punto de partida.

No hay una respuesta correcta para esto. Depende de para qué uses la base de datos. En una aplicación ENterprise, usted ingresó al inicio de sesión en la base de datos mediante claves foráneas y restricciones y activadores, etc. porque es el único lugar donde todas las aplicaciones posibles comparten código. Además, poner la lógica requerida en el código generalmente significa que la base de datos es inconsistente y que los datos son de baja calidad. Eso puede parecer trivial para un desarrollador de aplicaciones que solo se preocupa por cómo funciona la GUI, pero le aseguro que a las personas que intentan usar los datos en los informes de cumplimiento les resulta muy molesto y costoso cuando obtienen multas de mil millones de dólares por tener datos que no tienen. No sigas las reglas correctamente.

En un entorno no regular, cuando no te importa todo el conjunto de registros y solo una o dos aplicaciones llegan a la base de datos, tal vez puedas mantener todo en la aplicación.

Después de unos años, la pregunta sigue siendo importante ...

Una simple regla de oro para mí: si es una restricción lógica o una expresión ubicua (declaración única), colóquela en la base de datos (sí, ¡las claves externas y las restricciones de verificación también son lógica de negocios!). Si es de procedimiento, al contener bucles y ramas condicionales (y realmente no se puede cambiar en una expresión), póngalo en código.

Evitar las bases de datos de volcado de basura

Los intentos de colocar realmente toda la lógica empresarial en el código de la aplicación probablemente degenerarán la base de datos (relacional) en un basurero, donde el diseño relacional se omite completamente, los datos pueden tener un estado incoherente y falta la normalización (a menudo principalmente XML, JSON, CSV, etc. columnas de basura).

Este tipo de lógica de solo aplicación es probablemente una de las razones principales del aumento de NoSQL; por supuesto, con la desventaja de que la aplicación tiene que cuidar toda la lógica en sí, lo que se ha incorporado en el DB relacional durante décadas. . Sin embargo, las bases de datos NoSQL son más adecuadas para este tipo de manejo de datos, por ejemplo, los documentos de datos mantienen una "integridad relacional" implícita dentro de ellos mismos. Para las bases de datos relacionales, es simplemente abuso, causando cada vez más problemas.

Expresiones (basadas en conjuntos) en lugar de código de procedimiento

En el mejor de los casos, cada consulta u operación de datos debe codificarse como una expresión, en lugar de un código de procedimiento. Un gran soporte para esto es cuando los lenguajes de programación admiten expresiones, como LINQ en el mundo .NET (desafortunadamente, solo consultas actualmente, sin manipulación). En el lado de la base de datos relacional, se ha enseñado durante mucho tiempo, a preferir expresiones de sentencias de SQL en lugar de bucles de cursor de procedimiento. Por lo tanto, la base de datos puede optimizar, hacer la operación en paralelo o lo que sea útil.

Utilizar mecanismos de integridad de datos de DB

Cuando se trata de RDBMS con restricciones de clave externa y verificación, columnas calculadas, posiblemente activadores y vistas, este es el lugar para almacenar la lógica de negocios básica en la base de datos. La normalización adecuada ayuda a mantener la integridad de los datos, para garantizar una instancia única y distinta de los datos. ¡Incluso si tiene que duplicarlo en el código y en la base de datos, estos mecanismos básicos de integridad de datos no deben omitirse!

¿Procedimientos almacenados?

Los procedimientos almacenados rara vez son necesarios en la actualidad, ya que las bases de datos mantienen los planes de ejecución compilados para SQL y los reutilizan cuando vuelve la misma consulta, solo con diferentes parámetros. Así que el argumento de precompilación para SPs ya no es válido. Uno puede almacenar o generar automáticamente consultas SQL en la aplicación u ORM, que encontrará planes de consulta precompilados la mayor parte del tiempo. SQL es un lenguaje de expresión, siempre y cuando no utilice explícitamente elementos de procedimiento. Entonces, en el mejor de los casos, utiliza expresiones de código que pueden traducirse a SQL.

Mientras que el lado de la aplicación, incluido el ORM generado, SQL, ya no está dentro de la base de datos, a diferencia de los procedimientos almacenados, todavía lo cuento como código de base de datos. Debido a que aún requiere conocimientos de SQL y bases de datos (excepto el CRUD más simple) y, si se aplica correctamente, funciona de manera muy diferente al código de procedimiento generalmente creado con lenguajes de programación como C # o Java.

Realmente depende del negocio, su cultura y su legado. Dejando de lado las consideraciones técnicas (estas han sido cubiertas desde ambos lados), las respuestas proporcionadas le dicen que todo se reduce a la procedencia de las personas. En algunas organizaciones, los datos son el rey y el DBA es una figura poderosa. Este es su entorno centralizado típico, un centro de datos con un montón de terminales conectados a él. La preferencia en este tipo de ambiente es clara. El escritorio puede cambiar radicalmente muchas veces antes de que algo cambie en el centro de datos y habrá poco entre ellos.

El otro extremo del espectro es la arquitectura pura de 3 niveles. O tal vez multi-nivel en un negocio orientado a la web. Tu voluntad probablemente escuchará una historia diferente aquí. El DBA, si hay alguno, será solo un compañero que realizará algunas tareas administrativas.

Un desarrollador de aplicaciones de los tiempos modernos tendrá más afinidad con el segundo modelo. Si crecieras con un gran sistema cliente-servidor, probablemente estarías en el otro campo.

A menudo hay muchos factores no técnicos relacionados con el entorno involucrados aquí, no hay una respuesta general a esta pregunta.

El término lógica de negocios está abierto a interpretación. Al construir sistemas, queremos garantizar la integridad de la base de datos y su contenido. Como primer paso, debe haber diferentes concesiones de acceso de usuarios en su lugar. Como un ejemplo muy simple, consideremos una aplicación de cajero automático.

Para obtener el saldo de la cuenta, debe hacer una selección en una vista apropiada. Pero para transferir fondos, desearía que la transacción se encapsule mediante un procedimiento almacenado. No se debe permitir a la lógica de negocios actualizar directamente las tablas para los montos de crédito y débito.

En este ejemplo, la lógica de negocios podría verificar el saldo antes de solicitar la transferencia o simplemente invocar el proceso almacenado para la transferencia e informar el error. En mi humilde opinión, la lógica de negocios, en este ejemplo, debe verificar preventivamente que haya fondos suficientes disponibles y que exista la cuenta de destino y solo entonces invocar los fondos de transferencia. Si ocurre otro débito entre los pasos iniciales y la invocación de proc almacenada, solo entonces se devolverá un error.