¿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? [cerrado]

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?

Editar Esta pregunta también se trata en dba.se , desde la perspectiva de los DBA. Como programmers.se y dba.se tienen diferentes audiencias y sesgos, los futuros lectores pueden querer revisar ambos conjuntos de respuestas antes de decidir qué funciona mejor para ellos.

Fuera de mi cabeza, las ventajas de poner lógica en la capa de aplicación.

1. La capacidad de prueba . Esta debería ser una razón suficientemente buena por sí misma en realidad.
2. Mejor estructura de código . Es muy difícil seguir una arquitectura OO adecuada con SQL. Esto generalmente también hace que el código sea más fácil de mantener.
3. Más fácil de codificar . Debido a todas las características de idioma diferentes disponibles en cualquier idioma que esté utilizando, generalmente es más fácil codificar en la capa de aplicación.
4. Reutilización de código . Es mucho más fácil compartir código con bibliotecas que compartir código en la base de datos.

Si bien es posible utilizar el control de versiones con procedimientos almacenados (por ejemplo, las herramientas de base de datos Redgate se integran con TFS), no siempre es tan sencillo como lo es con el código de la aplicación.

Mi posición predeterminada es que la lógica debe mantenerse fuera de la capa de la base de datos, sin embargo, hay momentos en que sería más eficiente implementar la lógica en la base de datos. Si ese es el caso, debe asegurarse de que puede rastrear los cambios a este código.

En una empresa en la que trabajé, había muchos trámites burocráticos relacionados con la publicación del código a producción y la participación de un DBA para la publicación de un código siempre fue una pesadilla. Siempre ponemos la lógica en la capa de aplicación para eliminar tener que lidiar con DBA con los que fue difícil trabajar. Es una razón totalmente lamentable, pero derivada de la necesidad.

Poner la lógica de la aplicación en el DB me parece una mala idea. OTOH poner lógica en la base de datos que es específicamente parte del mantenimiento del estado de la base de datos (por ejemplo, disparadores / sprocs para actualizar tablas desnormalizadas) es una propuesta muy diferente.

Alternativamente, esto puede expresarse como: existen buenos argumentos para poner la lógica necesaria para abstraer cómo funciona realmente la base de datos de cómo quiere que se vea en la base de datos.

Después de leer ambas preguntas, creo que todos hemos perdido un punto crítico. La respuesta correcta puede depender del tipo de software que esté desarrollando. El grupo DBA tiende en gran parte a trabajar en sistemas empresariales críticos de software empresarial y sus respuestas tienden a reflejar lo que es necesario en ese mundo. Hay una gran diferencia entre lo que se necesita para ese tipo de aplicaciones y lo que se necesita para la próxima aplicación "Facebook". No es gran cosa si pierde un par de publicaciones en el muro, lo es si pierde un par de pedidos u otras transacciones financieras.

Las personas que trabajan en el mundo COTS (comercial fuera de la plataforma) tienden a necesitar ser independientes de la base de datos por razones de ventas y quieren todo en el código cumplido para que sea más difícil realizar ingeniería inversa y reemplazar su producto con uno de cosecha propia. Las aplicaciones empresariales desarrolladas y mantenidas internamente casi nunca necesitarán cambiar los backends de la base de datos, excepto para actualizar.

Las aplicaciones empresariales también son las que tienden a tener entradas de muchos lugares, siendo la base de datos la única característica común. El sistema en el que trabajo tiene cientos de aplicaciones diferentes que acceden a él, así como cientos de importaciones de datos de clientes, exportaciones de datos a clientes y almacenes de datos, y utiliza múltiples sistemas de informes. El código que funciona bien al agregar un registro falla cuando tengo que importar 20,000,000. Nos vimos obligados a usar la capa de aplicación una vez porque allí era donde estaba la lógica y tuvimos que detener el proceso 18 horas después sin terminar. La lógica que debe aplicarse a todos los registros de datos en una tabla debe estar en la base de datos cuando no puede tener una capa de datos que todos usen.

Por el contrario, cuando solo una aplicación consumirá los datos y los datos no son el elemento vital de su empresa o son efímeros, las reglas son diferentes y tiene más sentido poner toda la lógica en la aplicación.

Bastante largo. ver Resumen al pie.

RDBMS

Un RDBMS significa sistema de gestión de bases de datos relacionales. Es un sistema para administrar una base de datos relacional. Los datos se almacenan allí. Los datos. No dice lógica de negocios.

Procesos de negocio

¿Qué significa realmente la lógica de negocios? Para mí, es una descripción de los procesos comerciales en términos lógicos.

Los procesos son aquellas actividades comerciales que ocurren regularmente, lo suficiente como para que ya no sean ad hoc. Estos son diferentes para cada negocio.

Permítanme ponerme mi límite de negocios y explicar qué significa negocio aquí. Para algunos, esto puede ser una sorpresa.

Negocio

Los negocios son la suma de las actividades realizadas para lograr la creación de valor, y más específicamente el valor que se puede negociar. Esto podría significar hacer cosechadoras, emparedados de atún o proporcionar servicios bancarios. En la mayoría de los países del mundo, incluso en los sistemas no capitalistas, a las personas les gusta obtener el mayor valor por su dinero, y por lo tanto, hay competencia entre los diferentes proveedores de estos bienes y servicios valiosos. La competencia generalmente depende del precio, la calidad y la disponibilidad.

Desvío rápido: necesita 40 millones de remaches en 2 días, no va a ordenar a un tipo en Internet con una cuenta de PayPal, sin importar cuánto más barato sea su precio que el de su proveedor normal.

Conocimiento del proceso

Como puede imaginar, los procesos involucrados en la creación de este "valor" viven principalmente en los jefes ejecutivos. Algo de eso se pone en papel y se usa como políticas y procedimientos de la compañía. Algo de eso vive en las cabezas de los abogados corporativos. Mucho de eso vive en la cabeza de las personas que dirigen las divisiones, departamentos, equipos y los que manejan las máquinas, las cajas registradoras, los hornos, los camiones. Un pequeño subconjunto de eso reduce los requisitos comerciales para el software, y un subconjunto aún más pequeño es preciso cuando se implementa en los sistemas informáticos.

Al final, la lógica empresarial que se ve en el código no es la que ejecuta una empresa, es la que ejecuta la aplicación para la empresa. Los cerebros reales dentro de las personas reales mantienen los procesos comerciales reales, y no tienen problemas para entender que el proceso en su cerebro es más preciso que el proceso en la computadora. Por otro lado, probablemente no podría ejecutar el negocio si todo lo que tuviera fueran las políticas y procedimientos de la mayoría de las corporaciones. Muy a menudo estos son extremadamente inexactos, a pesar de los esfuerzos hercúleos.

Entonces, al final, es la lógica de la aplicación la que está codificada en el software. Y la gente quiere poner eso en la base de datos, porque los vendedores del sistema de administración de bases de datos han hecho afirmaciones grandiosas.

Lógica de aplicación

Yo digo que no. Digo que la lógica de la aplicación permanece dentro de la aplicación. Los datos van a la base de datos, de una manera muy normalizada, y luego se envían ETL al datawarehouse para informar, perforar, acumular, pivotar y cubicar.

Datos

También digo que los datos sobreviven a la aplicación, por lo que el esfuerzo de normalización de datos no debe ser específico de la aplicación, ni siquiera específico de la empresa, sino que debe ser general de la empresa. ¿Almacena códigos de estado? Debe usar INCITS 38: 2009 (http://www.census.gov/geo/www/ansi/statetables.html) porque es portátil en todas las empresas. Esto también facilita que múltiples aplicaciones manipulen los datos.

NoSQL?

Si trata la base de datos como parte del código de la aplicación, desde el diseño de las tablas hasta los desencadenantes, los procedimientos almacenados y los formatos de datos, esencialmente está utilizando la base de datos empresarial como un BerkleyDB glorificado, que es una estructura de archivos planos glorificada, que en realidad solo son listas persistentes. Esto es esencialmente lo que NoSQL está haciendo: volver a las raíces, pero hacerlo de manera multiproceso, persistente y tolerante a fallas.

Código actual

No, debe tratar la base de datos como un depósito común de datos para múltiples aplicaciones, tanto actuales como futuras. Ahora llegamos al quid de mi argumento. Los procesos comerciales cambian con los caprichos del mercado, la política y la moda. Muy a menudo cambian más rápido de lo que los codificadores pueden gestionar con lenguajes de grado informático (Java, C #, C ++, etc.) y terminan siendo escritos en VBA en hojas de cálculo de Excel en el departamento de contabilidad o marketing. (Y solo si no se puede expresar en vlookups elegantes ...)

Degradación de la base de datos

Los datos no cambian mucho si están bien organizados. La lógica empresarial cambia muy rápido. Al poner la lógica de negocios en la base de datos, hace que la base de datos sea menos valiosa, ya que se volverá obsoleta e inexacta antes.

Resumen

Los datos deben sobrevivir a la aplicación porque los procesos comerciales viven en la aplicación y los procesos comerciales cambian con mucha más frecuencia. Incluir la lógica de negocios en la base de datos es malo por su longevidad y valor general.

Consideración

He hecho mi parte de dba-ing y he leído las respuestas en dba.se pero, con toda honestidad, de lo que están hablando es de problemas de integridad de datos y problemas de rendimiento. Estoy completamente de acuerdo en que las personas que tocan datos corporativos deben saber lo que están haciendo, ya sea dba o programador o analista senior de SAS con acceso de lectura / escritura.

También noté que recomiendan que los codificadores conozcan SQL. Estoy de acuerdo. Es un lenguaje de programación de computadoras, así que no veo por qué los programadores de computadoras no quieren saberlo.

Más tarde, después de pensarlo

Creo que el término medio es hacer una API, y hacer que esa API administre el flujo de datos de un lado a otro. Si no puede permitir que las aplicaciones se conecten directamente a las tablas, al menos puede hacer que el mecanismo de acceso esté en los idiomas modernos.

A riesgo de sonar dramático, estoy realmente horrorizado por la idea de la lógica de la aplicación en la base de datos. Muchas de las respuestas aquí se han centrado en las ventajas de desarrollo de software, por lo que, en aras de la brevedad, me centraré en las ventajas que ofrece la división de responsabilidad.

Las bases de datos proporcionan un medio eficiente para almacenar y acceder a la información, al tiempo que minimizan los datos redundantes y producen relaciones lógicas en los datos. Si bien la lógica de la base de datos podría ser capaz de implementar la lógica empresarial de nivel de producción, mi opinión personal es que la base de datos debe ser lo más independiente de la aplicación posible para garantizar que los datos puedan ser aprovechados de manera efectiva por múltiples aplicaciones mientras se juega con las fortalezas respectivas de la base de datos motor versus las fortalezas del lenguaje de implementación de la aplicación.

Un usuario en el intercambio de pila DBA declaró esto ...

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

Las últimas Fortune 500 en las que trabajé tenían 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.

... Seguido de su creencia de que esto es indicativo de una violación del principio DRY.

En lugar de ser una repetición de la lógica empresarial, creo que es más probable que sea un ejemplo perfecto de la flexibilidad proporcionada por una división de responsabilidades distinta entre la capa empresarial y la capa de datos.

¡Su base de datos OLTB ha estado proporcionando datos de manera confiable y eficiente a más de 25 aplicaciones durante décadas! ¡Eso es increíble! (¡Camino a seguir!)

Solo puedo suponer que los datos son lo suficientemente agnósticos para proporcionar contenido para varias aplicaciones distintas. Algo que sería en gran medida imposible si esos desarrolladores intentaran piratear algo juntos usando la lógica de la base de datos.

Como han indicado otras respuestas, hay muchas otras razones para no implementar un programa en la base de datos. Estoy seguro de que funcionaría, pero el resultado más probable sería décadas de arrepentimiento, en lugar de décadas de estabilidad.

Las aplicaciones independientes de la base de datos requieren toda la lógica fuera de las bases de datos. Es muy difícil construir y mantener código para muchos proveedores de bases de datos diferentes.

Un buen desarrollo logrará un buen equilibrio entre la necesidad de integridad y velocidad de la base de datos al poner parte de la lógica en la base de datos y la mayor parte en la aplicación.

¿Se usará la misma consulta una y otra vez en muchas aplicaciones, entonces quizás pertenezca a un procedimiento almacenado.

Asegurarse de que los campos de mantenimiento se establezcan cuando se inserta y actualiza una fila es responsabilidad del DBA. Se usará un disparador.

Por otro lado, si tengo lógica de negocios, debe estar en la aplicación. Cuando sea posible, debe realizar llamadas a procedimientos almacenados que devolverán el conjunto de registros filtrado deseado con la cantidad exacta de campos necesarios. Ni más ni menos.

Es una cuestión de comunicación entre equipos y una cuestión de reconocer los pros y los contras de cada posibilidad.

Mi opinión es: no haga que la lógica de la aplicación sea demasiado profunda en DB.

Algunos sistemas de negociación proporcionan una forma de ampliar la funcionalidad existente con scripts, básicamente colocados en la base de datos. Mi experiencia con esto es bastante negativa, al menos en una configuración multiusuario.

Pondría la lógica en una base de datos, porque querría poder modificar esa lógica fácilmente.

• ¿Cómo harías el control de versiones?
  • ¿Cuál es el historial del código? ¿Cuáles fueron los cambios? ¿Por quién?
  • ¿Cómo manejas los cambios en los mismos fragmentos de código?
• ¿Cómo identificaría y garantizaría un estado de código coherente?

Puede realizar un seguimiento de esto en un VCS adicional basado en archivos, pero ¿cuál es el beneficio de la base de datos?

La mayoría de las aplicaciones necesitan tener alguna forma de proporcionar integración. Lo ideal sería tener una API completa, un servicio web o al menos poner a disposición algunos objetos de base de datos que contengan lógica empresarial. Todos no están en una posición de tiempo / recursos para construir una API, por lo que debe comprometerse.