Lógica de negocios: Base de datos vs código [duplicado]

Consulte ¿Cuánta lógica empresarial debe implementar la base de datos? para discusión previa.

En general, todos quieren que las cosas se hagan en la capa que controlan. Porque entonces lo controlan.

Todos los proveedores de bases de datos desean que las personas pongan tanta lógica en la base de datos como sea posible. Porque eso te encierra en la base de datos. El razonamiento es que si varias aplicaciones usan la misma base de datos, reutilizarán el código.

Sin embargo, los programadores están enfáticamente en desacuerdo. Las bases de datos ofrecen pocas opciones de programación. Implementar código en bases de datos es difícil. Las bases de datos carecen de herramientas básicas para el control de revisiones, la edición interactiva, la implementación y las pruebas unitarias. Los procedimientos almacenados tienden a involucrar situaciones horribles de depuración a distancia. Se ha vuelto menos común que varias aplicaciones lleguen a la misma base de datos. Y si alguna vez tiene que hacer algo de escala, el único cuello de botella más difícil de solucionar es su base de datos.

Mi sesgo es claro. Soy programador.

Pero he estado programando durante casi 20 años, principalmente como programador de servicios de fondo que es responsable de los datos. He visto el argumento muchas veces para mover la lógica a la base de datos. He visto sistemas que lo hicieron, y sistemas que lo evitaron. He tenido que migrar bases de datos, migrar bases de código, etc., etc., etc.

Los peores problemas siempre han sido cuando la lógica de negocios estaba en la base de datos. Siempre fueron los más difíciles de arreglar. Y puedo decir que, aunque muchas veces he encontrado la afirmación de que "movimos la lógica a la base de datos para el rendimiento", el rendimiento casi siempre es mejor con un modelo de datos normalizado y limpio, buenos índices, una capa de almacenamiento en caché frente a la base de datos, y algoritmos sanos implementados en un lenguaje de programación moderno.

Creo firmemente que siempre que sea posible , la lógica empresarial debe mantenerse en la capa de software y no en la capa de base de datos. Tenga en cuenta que siempre que sea posible está lejos de siempre .

Hay argumentos sólidos para ambas formas y, como siempre, utilice el buen criterio de ingeniería para decidir para cada proyecto cuánto peso debe aplicarse a cada punto antes de decidir cuál es la opción más adecuada.

( como otras personas hacen sugerencias en los comentarios, se pueden agregar a la lista )

Argumentos para la base de datos que maneja la lógica empresarial:

• La lógica de negocios necesita datos para operar. Obtener el procesamiento lógico lo más cerca posible de los datos proporciona un mejor rendimiento
• Un lugar para aplicar actualizaciones

Argumentos para las capas de software que manejan la lógica empresarial:

• El software bien escrito suele ser mucho más fácil de entender, depurar y mantener que los procedimientos almacenados de SQL.
• Los servidores de aplicaciones pueden escalar y escalar si la aplicación de Internet se vuelve popular.

Como desarrollador profesional experimentado, que necesita una solución rápida para mejorar la latencia de la aplicación, la opción puede ser entre mover un poco de lógica de negocios de ejecución lenta a un procedimiento almacenado en la base de datos y / o para implementar el almacenamiento en caché de procesos lentos.

Sin embargo, hay un problema serio con la lógica de negocios basada en bases de datos. Si su aplicación necesita escalar de forma masiva, siempre prefiera sistemas / procesos que puedan escalarse (con esto quiero decir, puede agregar más servidores al grupo de procesamiento). Las bases de datos SQL solo pueden ampliarse (necesita encontrar un servidor más potente para reemplazar el existente). Si su aplicación tiene mucha lógica empresarial de base de datos, llegará a este problema antes.

Faltan dos puntos muy importantes en los argumentos de la base de datos pro:

• rendimiento : el código de la base de datos se ejecuta con acceso directo a los datos, evitando así transferencias innecesarias (ya sea a través de API de búsqueda y esquemas de mapeo en la misma máquina, o a través de la red para la comunicación cliente / servidor)
• consistencia : dado que varias aplicaciones pueden acceder / actualizar la misma base de datos, encapsulando la coherencia y las reglas de negocios de manera centralizada en ellas, se garantiza que se cumplirán de manera confiable.

Pero también faltan algunos puntos muy importantes en sus argumentos contra-base de datos:

• escalabilidad : cuanto más coloque en la base de datos, más se convertirá este componente en un cuello de botella. Por supuesto, puedes tomar servidores más grandes y agregar CPU, pero tarde o temprano cumplirás con los límites físicos.

• bloqueo de proveedor : SQL está muy estandarizado, pero los lenguajes para los activadores y los procedimientos están bastante diversificados y, a menudo, son propietarios: T-SQL para Microsoft, PL / SQL para Oracle, cualquier idioma para DB2. Desarrollar en la base de datos lo bloquea para un proveedor, y no le permite beneficiarse de una mayor competencia, o migrar a nuevos entornos operativos.

• arquitectura heredada : sobrecentralización de datos y procesamiento en servidores enormes ... ¿Esto no nos devuelve a la era de los mainframes? Esto parece obsoleto en la actualidad, cuando surgen nuevas tendencias arquitectónicas que apuntan a una escalabilidad máxima: flexible NoSQL bases de datos de diferentes tipos ideales para el desarrollo orientado a objetos , microservices con cada microservicio que tiene su propia base de datos, y una arquitectura de datos grandes como lambda architectures donde todas las tuberías de procesamiento están fuera de la base de datos.

• argumentos obsoletos : el tiempo de error propenso al código cobol redundante copiado en todas las aplicaciones ha terminado. Lo que solo pudo encapsularse de manera confiable en un RDBMS ayer, puede encapsularse muy bien en arquitecturas de software modernas, utilizando componentes orientables a objetos, bibliotecas y sistemas de control de versiones, mantenibles y reutilizables.

Para resumir:

• sí, hay argumentos válidos para poner el máximo de lógica en el lado de la base de datos. Sin embargo, estos argumentos ya no satisfacen las nuevas necesidades y limitaciones de la escala de Internet, el cambio tecnológico y la aparición de bigdata.
• no, no creo que haya un mejor enfoque universal. El enfoque más adecuado será elegido por un arquitecto de software, caso por caso, en función de los requisitos y necesidades concretos.

Además de todos los hechos que ya se han señalado, también recuerde que tener lógica de negocios en su código en lugar de que la base de datos finalmente sea más barata.

Al buscar un desarrollador para una aplicación escrita en PHP y usar MySQL como base de datos, si su lógica de negocios se almacena en la base de datos, un simple programador de PHP no es suficiente, y tendrá que encontrar a alguien que también sepa escribir , depurar y optimizar procedimientos almacenados. De repente, necesitas un tipo que sepa no solo una cosa, PHP, sino dos, programación PHP y MySQL.

Y ni siquiera pienses en cambiarte a un motor de mayor rendimiento como PostgreSQL , entonces también necesitas contratar un chico para transformar todos los procedimientos almacenados a PL / SQL .

Al tener lógica de negocios en el código, esto es solo una cuestión de escribir una nueva capa de abstracción para PostgreSQL y cambiar las dependencias en su aplicación, boom, su aplicación de repente conoce PostgreSQL.

Las respuestas anteriores dan buenas razones para explicar por qué es más fácil / mejor poner la lógica en el código de la aplicación en una base de datos. Una excepción que me gustaría resaltar es cuando se utiliza una base de datos / pila de datos de big data. En este caso, muchas de las desventajas desaparecen:

• Puedes escribir pruebas unitarias ya que el código real que escribiste se encuentra en la base de datos.
• Puede depurar, aunque a través de pruebas unitarias.
• Tienes control de versiones, ya que es código.

Y las ventajas de tener lógica en la base de datos son mucho más importantes:

• Dependiendo de la cantidad de datos que se estén procesando, podría no ser razonable enviar datos a su código de aplicación.
• Escala: su código se escala igual que la base de datos; en muchos casos, el rendimiento y el almacenamiento son lineales en el número de nodos (máquinas).

Gran pregunta: esto es algo que defiendo en la oficina con mucha frecuencia.

Mi opinión es que la mayoría de la lógica debe estar en código. Siempre es muy tentador usar una variedad de idiomas porque cada uno tiene sus puntos fuertes, pero a menos que tenga una configuración de desarrollo perfecta (lo cual es muy raro), es preferible utilizar un solo idioma.

La gente ha mencionado la versión de control de unidades / revisión de unidades, pero una cosa muy importante es la implementación. Tener que sincronizar los cambios de código de la base de datos con los cambios de código puede ser peligroso.

Si estás en una empresa de desarrollo de software a gran escala, es posible que tengas suficientes personas especializadas que conozcan cualquiera de las partes (programación de base de datos vs codificación), pero de lo contrario es difícil encontrar personas que puedan hacer malabares entre los dos mundos (y la mayoría lo que es más importante, quién hace las compensaciones correctas cuando se trata de decidir qué parte de la lógica debe estar en qué idioma).

Personalmente, encuentro que los lenguajes de programación SQL son muy primitivos, y las herramientas de desarrollo para ellos son aún peores. Así que yo preferiría los lenguajes de programación modernos. Un buen ORM puede evitar que la mayoría de los desarrolladores sepan nada sobre la base de datos, y vale la pena invertir en él. La gente mencionó la eficiencia de hacer las cosas del lado del servidor, y esto no debe ser abandonado. Hay algunos patrones de programación muy agradables que permiten expresar operaciones del lado del servidor usando lo que parece ser una API del lado del cliente (por ejemplo, IQueryable en C #).

En la práctica, todavía estoy usando las vistas extrañas o los procedimientos almacenados, pero generalmente son en su mayoría puros para la agregación y no tienen ninguna lógica "comercial". Esto es bastante útil, ya que se pueden usar como fuentes para tablas dinámicas de Excel, por ejemplo.