database - que - mongodb español
Lógica empresarial: base de datos o capa de aplicación (24)
La vieja pregunta. ¿Dónde debería poner su lógica comercial, en la base de datos como procedimientos almacenados (o paquetes), o en la aplicación / nivel medio? Y más importante, ¿por qué?
Suponer que la independencia de la base de datos no es un objetivo.
¡Esta es una gran pregunta! Lo encontré después de que ya había hecho una question similar, 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 tienes millones de filas de datos en las tablas de tu base de datos, entonces considera poner la lógica de negocios en procedimientos almacenados y factores desencadenantes. Eso es lo que estamos haciendo en este momento, convirtiendo una aplicación java en procedimientos almacenados para la mantenibilidad ya que el código de Java se ha complicado.
Encontré este artículo en: The Business Logic Wars. El autor también hizo millones de filas en un argumento de tabla, que me pareció interesante. También agregó la lógica empresarial en javascript, que es del lado del cliente y está fuera del nivel lógico de negocios. No había pensado en esto antes, aunque utilicé JavaScript para la validación durante años, junto con la validación del lado del servidor.
Mi opinión es que quiere la lógica empresarial en la aplicación / nivel medio como regla general, pero no descarte los casos en los que tenga sentido incluirlos en la base de datos.
Un último punto, hay otro grupo en el que estoy trabajando actualmente que está haciendo un trabajo de base de datos masivo para la investigación y la cantidad de datos que están tratando es inmensa. Aún así, para ellos no tienen ninguna lógica comercial en la base de datos en sí, sino que 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.
Depende de usted, siempre que sea coherente .
Una buena razón para ponerlo en su capa de base de datos: si está bastante seguro de que sus clientes nunca cambiarán 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 debe tener en cuenta las competencias básicas. ¿Sus desarrolladores son principalmente desarrolladores de capas de aplicaciones, o son principalmente tipos de DBA?
En mi humilde opinión. Hay dos preocupaciones conflictivas al decidir dónde va la lógica de negocios en una aplicación relacional basada en bases de datos:
- mantenibilidad
- confiabilidad
Re. mantenimiento: para permitir un desarrollo eficiente en el futuro, la lógica de negocios pertenece a la parte de su aplicación que es más fácil de depurar y control de versiones.
Re. Fiabilidad: cuando existe un riesgo significativo de incoherencia, la lógica comercial pertenece a la capa de la base de datos. Las bases de datos relacionales pueden diseñarse para verificar las restricciones en los datos, por ejemplo, no permitir valores NULL en columnas específicas, etc. Cuando surge un escenario en el diseño de la aplicación donde algunos datos deben estar en un estado específico que es demasiado complejo para expresar con estos simples restricciones, puede tener sentido utilizar un disparador o algo similar en la capa de la base de datos.
Los desencadenadores son un problema para mantenerse actualizado, especialmente cuando se supone que su aplicación se ejecuta en sistemas cliente a los que ni siquiera tiene acceso. Pero eso no significa que sea imposible hacer un seguimiento de ellos o actualizarlos. Los argumentos de S.Lott en su respuesta de que es un dolor 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 por primera vez su capa de datos 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ía de la lógica empresarial está contenida en la capa del modelo de la aplicación, por ejemplo, una factura sabe cómo inicializarse a partir de un pedido de venta determinado. Cuando un grupo de cosas diferentes se modifican secuencialmente para un conjunto complejo de cambios como este, los enrollamos en una transacción para mantener la coherencia, en lugar de optar por un procedimiento almacenado. El cálculo de los totales, etc., se realiza con métodos en la capa del modelo. Pero cuando necesitamos desnormalizar algo para el rendimiento o insertar datos en una tabla de "cambios" utilizada por todos los clientes para determinar qué objetos necesitan caducar en su caché de sesión, usamos desencadenantes / funciones en la capa de la base de datos para insertar una nueva fila y enviar una notificación (Postgres escuchar / notificar cosas) desde este desencadenador.
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 comenzáramos desde cero sería diseñar nuestro sistema para crear funciones de base de datos (o procedimientos almacenados, sin embargo, desea llamarlos) con versiones y actualizaciones en mente desde el principio.
Afortunadamente, contamos con algún sistema para hacer un seguimiento de las versiones de esquema, por lo que construimos algo además de eso para encargarnos de reemplazar las funciones de la base de datos. Nos habría ahorrado algún tiempo si hubiéramos considerado la necesidad de reemplazarlos desde el principio.
Por supuesto, todo cambia cuando sales del reino de los RDBMS en sistemas de almacenamiento tuple como Amazon SimpleDB y BigTable de Google. Pero esa es una historia diferente :)
Es un continuo. En mi humilde opinión, el factor más importante es la velocidad. ¿Cómo se puede poner en marcha esta bomba tan pronto como sea posible sin dejar de lado a los buenos inquilinos de la programación como el mantenimiento, el rendimiento, la escalabilidad, la seguridad, la fiabilidad, etc. A menudo, SQL es la forma más concisa de expresar algo y también resulta ser el más eficiente muchas veces, excepto por operaciones de cadena, etc., pero es ahí donde sus CLR Procs pueden ayudar. Mi creencia es rociar liberalmente la lógica de negocios alrededor de donde se sienta que es mejor para la empresa en cuestión. Si tiene un grupo de desarrolladores de aplicaciones que se cagan de pan al mirar SQL, entonces déjenles usar su lógica de aplicación. Si realmente desea crear una aplicación de alto rendimiento con grandes conjuntos de datos, ponga tanta lógica en el DB como pueda. Encienda sus DBA y otorgue a los desarrolladores la máxima libertad sobre sus bases de datos Dev. No hay una respuesta o 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 está gastando mucho más tiempo escribiendo SQL expreso agradable y expresivo donde lo justifica y utilizando la capa de aplicación en otras ocasiones. Para mí, en última instancia, reducir la cantidad de líneas de código es lo que conduce a la simplicidad. Acabamos de convertir una aplicación enriquecida sql con solo 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 rich sql. Si puede justificar un aumento de 6 veces en el código como "simplificado", continúe adelante.
Hoy en día es posible enviar a subversión su código de proceso almacenado y depurar este código con un buen soporte de herramientas.
Si utiliza procs almacenados que combinan sentencias SQL, puede reducir la cantidad de tráfico de datos entre la aplicación y la base de datos y reducir el número de llamadas a la base de datos y obtener grandes ganancias de rendimiento.
Una vez que empezamos a construir en C #, tomamos la decisión de no usar procs almacenados, pero ahora estamos moviendo más y más código a procs almacenados. Especialmente procesamiento por lotes.
Sin embargo, no use desencadenantes, use procs almacenados o mejores paquetes. Los disparadores disminuyen la capacidad de mantenimiento.
La capacidad de mantenimiento de su código siempre es una gran preocupación para determinar dónde debe ir la lógica de negocios.
Las herramientas de depuración integradas y los IDEs más potentes generalmente hacen que el mantenimiento del 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 de lo contrario, debe comenzar con la lógica comercial en su nivel / aplicación intermedia y no en los procedimientos almacenados.
Sin embargo, cuando se llega a informes y búsqueda / minería de datos, los procedimientos almacenados a menudo pueden 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 usted está manteniendo el procesamiento muy cerca de la fuente de los datos. Pero esto puede no ser lo que la mayoría considera lógica de negocios clásica de todos modos.
La escalabilidad es también un factor muy importante para utilizar la lógica empresarial en la capa intermedia o de aplicación que en la capa de la base de datos. Se debe entender que DatabaseLayer es solo para interactuar con la base de datos que no se manipula y que se devuelve a la base de datos.
La independencia de la base de datos, que el consultante descarta como una consideración en este caso, es el argumento más fuerte para sacar la lógica de la base de datos. El argumento más fuerte para la independencia de la base de datos es la posibilidad de vender software a las empresas con sus propias preferencias para un back-end de base de datos.
Por lo tanto, considero que el principal argumento para sacar los procedimientos almacenados de la base de datos es solo comercial, no técnico. Puede haber razones técnicas, pero también hay razones técnicas para mantenerlo allí: rendimiento, integridad y la capacidad de permitir que múltiples aplicaciones utilicen la misma API, por ejemplo.
La utilización o no de los SP también está fuertemente influenciada por la base de datos que va a utilizar. Si se toma en consideración la independencia de la base de datos, entonces va a tener experiencias muy diferentes usando T-SQL o usando PL / SQL.
Si está utilizando Oracle para desarrollar una aplicación, entonces PL / SQL es una opción obvia como idioma. Está estrechamente relacionado con los datos, se mejora continuamente en cada cambio, y cualquier herramienta de desarrollo decente integrará el desarrollo de PL / SQL con CVS o Subversion o algo así.
El entorno de desarrollo Application Express basado en la web de Oracle incluso está construido al 100% con PL / SQL.
La lógica comercial debe colocarse en la aplicación / nivel medio como primera opción. De esta forma, puede expresarse en forma de modelo de dominio, colocarse en control de fuente, dividirse o combinarse con código relacionado (refactorizado), etc. También le proporciona cierta independencia de proveedor de 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 código lo que debería estar sucediendo.
Las únicas buenas razones para colocar el código en los procedimientos almacenados son: si hacerlo produce un beneficio de rendimiento significativo y necesario o si el mismo código comercial debe ser ejecutado por múltiples plataformas (Java, C #, PHP). Incluso cuando se utilizan plataformas múltiples, existen alternativas tales como servicios web que podrían ser más adecuados para compartir la funcionalidad.
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 utiliza. 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 la lógica en un procedimiento almacenado para la optimización del rendimiento.
Lo que quiero decir es que la lógica empresarial se debe colocar en el nivel de la aplicación, pero hay excepciones (principalmente razones de rendimiento)
La lógica empresarial generalmente está incorporada por los objetos y los diversos constructos de lenguaje de encapsulación, herencia y polimorfismo. Por ejemplo, si una aplicación bancaria está pasando dinero, puede haber un tipo de dinero que define los elementos de negocio de lo que es "dinero". Esto, en contra de usar un decimal primitivo para representar dinero. Por esta razón, una POO bien diseñada es donde vive la "lógica de negocios", no estrictamente en ninguna capa.
La respuesta en mi experiencia se encuentra en algún lugar en un espectro de valores generalmente determinado por las habilidades de su organización.
El DBMS es una bestia muy poderosa, lo que significa que el tratamiento adecuado o inadecuado traerá un gran beneficio o un gran peligro. Lamentablemente, en demasiadas organizaciones, se presta atención primaria al personal de programación; Las habilidades de DBM, especialmente las habilidades de desarrollo de consultas (a diferencia de las administrativas) se descuidan. Lo cual se ve agravado por el hecho de que la capacidad de evaluar dbms también es probable que falte.
Y hay pocos programadores que entiendan lo que no entienden acerca de las bases de datos.
De ahí la popularidad de conceptos subóptimos, como Active Records y LINQ (para arrojar algunos sesgos obvios). Pero probablemente sean la mejor respuesta para tales organizaciones.
Sin embargo, tenga en cuenta que las organizaciones altamente escaladas tienden a prestar mucha más atención al uso eficaz del almacén de datos.
Las ''capas'' de la aplicación de negocios son:
1. Interfaz de usuario
Esto implementa la vista del usuario comercial del trabajo h (is / er). Utiliza términos con los que el usuario está familiarizado.
2. Procesamiento
Aquí es donde suceden cálculos y manipulación de datos. Cualquier lógica de negocio que implique cambios de datos se implementa aquí.
3. Base de datos
Esto podría ser: una base de datos secuencial normalizada (el DBMS estándar basado en SQL); una base de datos OO, que almacena objetos que envuelven los datos comerciales; etc.
Qué pasa Donde
Para llegar a las capas anteriores, debe hacer el análisis y el diseño necesarios. Esto indicaría dónde sería mejor implementar la lógica empresarial: las reglas de integridad de datos y las cuestiones de concurrencia / tiempo real con respecto a las actualizaciones de datos normalmente se implementarían lo más cerca posible de los datos, igual que los campos calculados, y este es un buen puntero a procedimientos almacenados / disparadores, donde la integridad de datos y el control de transacciones son absolutamente necesarios.
Las reglas comerciales que implican el significado y el uso de los datos se implementarían en su mayoría 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 una secuencia que refleja el trabajo del usuario
Lo único que entra 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 una fricción organizacional.
Es difícil mantener un buen control de versión sobre los procedimientos almacenados. El código fuera de la base de datos es realmente fácil de instalar: cuando piensas que tienes la versión incorrecta, simplemente haces una SVN UP (quizás una instalación) y tu aplicación vuelve a un estado conocido. Tiene variables de entorno, enlaces de directorio y mucho control de entorno sobre la aplicación.
Puede, con simples manipulaciones de PATH , tener variantes de software disponibles para diferentes situaciones (entrenamiento, prueba, 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 administrar. No existe un entorno adecuado, no hay "PATH", enlaces de directorio u otras variables de entorno, para proporcionar un control utilizable sobre qué software se está utilizando; tiene un conjunto de software de aplicación permanente y globalmente atorado en la base de datos, vinculado a los datos.
Los desencadenantes son aún peores. Ambos son una pesadilla de mantenimiento y depuración. No veo qué problema resuelven; parecen ser una forma de trabajar en aplicaciones mal diseñadas donde a alguien no se le puede molestar usar las clases disponibles (o bibliotecas de funciones) correctamente.
Si bien algunas personas consideran que el argumento del rendimiento es convincente, todavía no he visto suficientes datos de referencia para convencerme de que los procedimientos almacenados son muy rápidos. Todos tienen una anécdota, pero nadie tiene un código lado a lado donde los algoritmos son más o menos lo mismo.
[En los ejemplos que he visto, la aplicación anterior era un desastre mal diseñado; cuando se escribieron los procedimientos almacenados, la aplicación se rediseñó. Creo que el cambio de diseño tuvo más impacto que el cambio de plataforma.]
No hay una respuesta correcta independiente para esta pregunta. Depende de los requisitos de tu aplicación, las preferencias y habilidades de tus desarrolladores, y la fase de la luna.
Para casos muy simples puede poner su lógica comercial en procedimientos almacenados. Por lo general, incluso los casos simples tienden a complicarse con el tiempo. Estas son las razones por las que no pongo lógica comercial en la base de datos:
Poner la lógica comercial en la base de datos lo relaciona estrechamente con la implementación técnica de la base de datos. Cambiar una tabla provocará que modifiques una gran cantidad de procedimientos almacenados, causando muchos errores adicionales y pruebas adicionales.
Por lo general, la IU depende de la lógica comercial para cosas como la validación. Poner estas cosas en la base de datos causará un fuerte acoplamiento entre la base de datos y la UI o, en casos diferentes, duplicará la lógica de validación entre esas dos.
Será difícil tener múltiples aplicaciones que funcionen en la misma base de datos. Los cambios para una aplicación causarán que otros se rompan. Esto puede convertirse rápidamente en una pesadilla de mantenimiento. Entonces realmente no escala.
Más prácticamente, SQL no es un buen lenguaje para implementar la lógica empresarial de una manera comprensible. SQL es ideal para las operaciones basadas en conjuntos, pero se pierden las construcciones para "programar a lo grande", es difícil mantener grandes cantidades de procedimientos almacenados. Los lenguajes OO modernos son más adecuados y más flexibles para esto.
Esto no significa que no pueda usar procs y vistas almacenados. Creo que a veces es una buena idea poner una capa adicional de procedimientos almacenados y vistas entre las tablas y la (s) aplicación (es) para desacoplar las dos. De esta forma, puede cambiar el diseño de la base de datos sin cambiar la interfaz externa, lo que le permite refactorizar la base de datos de forma independiente.
Ponemos mucha lógica comercial en los procedimientos almacenados, no es ideal, pero a menudo es un buen equilibrio entre rendimiento y confiabilidad.
¡Y sabemos dónde está sin tener que buscar a través de acres de soluciones y código base!
Poner el código en la capa de aplicación dará como resultado una aplicación independiente de DB.
Algunas veces es mejor usar procedimientos almacenados por razones de rendimiento.
(Como de costumbre) depende de los requisitos de la aplicación.
Ponga suficiente lógica de negocios en la base de datos para garantizar que los datos sean consistentes y correctos.
Pero no tema duplicar parte de esta lógica en otro nivel para mejorar la experiencia del usuario.
Recuerdo haber leído un artículo en alguna parte que indicaba que todo puede ser, en cierto nivel, parte de la lógica de negocios, 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 una fecha vencida en rojo es una decisión comercial ...
Si bien hay beneficios para tener la lógica de negocios en la capa de aplicación, me gustaría señalar que los lenguajes / marcos parecen cambiar más frecuentemente que las bases de datos.
Algunos de los sistemas que soporto pasaron por las siguientes IU en los últimos 10-15 años: Oracle Forms / Visual Basic / Perl CGI / ASP / Java Servlet. Lo único que no cambió: la base de datos relacional y los procedimientos almacenados.
Si bien no hay una respuesta correcta, depende del proyecto en cuestión, recomendaría el enfoque defendido en " Diseño impulsado por el dominio " por Eric Evans. En este enfoque, la lógica empresarial está aislada en su propia capa, la capa de dominio, que se encuentra en la capa de infraestructura, que podría incluir el código de la base de datos y debajo de la capa de aplicación, que envía las solicitudes a la capa de dominio para el cumplimiento y escucha la confirmación de su finalización, conduciendo efectivamente la aplicación.
De esta forma, la lógica de negocios se captura en un modelo que se puede analizar con quienes entienden el negocio, aparte de los problemas técnicos, y debería facilitar el aislamiento de los cambios en las reglas del negocio, los problemas técnicos de implementación y el flujo de información. 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 realmente puede ser aproximado en el mundo real de código real y proyectos.
Si necesita independencia de la base de datos, probablemente quiera poner toda su lógica de negocios en la capa de aplicación, ya que los estándares disponibles en el nivel de la aplicación son mucho más frecuentes que los disponibles para el nivel de la base de datos.
Sin embargo, si la independencia de la base de datos no es el factor n. ° 1 y el conjunto de habilidades de su equipo incluye sólidas habilidades de base de datos, la lógica de negocios en la base de datos puede ser la mejor solución. Puede hacer que la gente de su aplicación haga cosas específicas de la aplicación y que la gente de la base de datos se asegure de que todas las consultas vuelen.
Por supuesto, hay una gran diferencia entre poder lanzar una instrucción SQL y tener "habilidades sólidas en la base de datos". Si tu equipo está más cerca de la primera que la segunda, entonces pon la lógica en la aplicación usando uno de los Hibernates de este mundo. (¡o cambia tu equipo!).
En 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 está en el negocio de 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 la aplicación.
Espero que ayude.
Todo lo que afecte la integridad de los datos debe colocarse en el nivel de la base de datos. Otras cosas además de la interfaz de usuario a menudo ponen datos, actualizan o eliminan datos de la base de datos, incluyendo importaciones, actualizaciones masivas para cambiar un esquema de precios, soluciones rápidas, etc. Si necesita asegurarse de que se sigan las reglas, ponga la lógica en los valores predeterminados y disparadores.
Esto no quiere decir que no sea una buena idea tenerlo también en la interfaz de usuario (¿por qué molestarse en enviar información que la base de datos no aceptará?), Pero ignorar estas cosas en la base de datos es un desastre judicial.