Puede 'mover la lógica de negocio a nivel de aplicación' aumentar el rendimiento?

Question

En mi proyecto actual, la lógica de negocio se implementa en los procedimientos almacenados (una de ellas de 1000) y ahora se desea modificar la escala hasta que el negocio está creciendo. Los arquitectos han decidido trasladar la lógica de negocio a nivel de aplicación (.NET) para aumentar el rendimiento y la escalabilidad. Pero ellos no están rediseñando / reescribir nada. En resumen las mismas consultas SQL que son disparados desde un SP serán disparados desde una función .NET utilizando ADO.Net. ¿Cómo puede producir cualquier actuación?

A lo mejor de mi entendimiento, tenemos que mover la lógica de negocio a nivel de aplicación cuando necesitamos la independencia DB o hay alguna lógica de negocio que puede ser mejor implementado en un lenguaje de programación orientada a objetos que un motor de RDBMS (como atravesar una jerarquía o alguna procesamiento de imágenes, etc ..). En resto de los casos, si no hay ninguna lógica de negocio complicado de implementar, creo que es mejor mantener la lógica de negocio en sí mismo DB, al menos, los retrasos en la red entre la capa de aplicación y la base de datos se pueden evitar de esta manera.

Por favor, hágamelo saber sus puntos de vista. Soy un desarrollador mirando algunas decisiones de arquitectura con un poco de vacilación, perdón por mi ignorancia en el tema.

Answer 1

Si la lógica de negocio se encuentra todavía en las sentencias SQL, la base de datos estará haciendo el mismo trabajo que antes, y que no va a obtener un mejor rendimiento. (Puede ser más trabajo si no es capaz de almacenar en caché planes de consulta como effectivily que cuando se utilizaron procedimientos almacenados)

Para obtener un mejor rendimiento tiene que mover un poco de trabajo a la capa de aplicación, se puede por ejemplo datos de caché en el servidor de aplicaciones y hacer una búsqueda o una comprobación de validación sin chocar con la base de datos?

Answer 2

argumentos arquitectónicos tales como estos a menudo tienen que considerar muchos oficios-off, teniendo en cuenta el rendimiento de forma aislada, o ideed considerar sólo un aspecto de rendimiento, como el tiempo de respuesta tiende a perder la imagen más grande.

Hay claramente algunas solución de compromiso entre la ejecución de la lógica en la capa de base de datos y el envío de los datos a la capa applciation y procesarla allí. Datos de Costes de buques frente a los costos de procesamiento. Como se indica el costo y la complejidad de la lógica de negocio será un factor importante, el tamaño de los datos que se enviarán sería otro.

Es concebible, si la capa de base de datos se está ocupado, que la descarga de procesamiento a otra capa puede permitir un mayor rendimiento global, incluso si el tiempo de las respuestas individuales se incrementan. entonces podríamos escalar el nivel de aplicación con el fin de hacer frente a alguna carga adicional. ¿Le ahora decir que el rendimiento ha sido mejorado (mayor rendimiento global) o empeorado (aumento soem en el tiempo de respuesta).

Ahora considerar si el nivel de aplicación podría poner en práctica estrategias de caché interesantes. Tal vez tenemos una gran victoria en el rendimiento - sin carga en la base de datos en absoluto para algunas peticiones

!

Answer 3

Creo que esas decisiones no deben justificarse mediante el dogma arquitectónico. Datos harían mucho más sentido.

Las declaraciones como "Toda la lógica de negocio pertenece en los procedimientos almacenados" o "Todo debe estar en el nivel medio" tienden a ser realizado por personas cuyo conocimiento se limita a las bases de datos u objetos, respectivamente. Mejor combinar tanto cuando se juzga, y lo hace sobre la base de mediciones.

Por ejemplo, si uno de sus procedimientos se crujido de una gran cantidad de datos y devolver un puñado de resultados, hay un argumento que dice que debe permanecer en la base de datos. Hay poco sentido en traer millones de filas en la memoria en el nivel medio, crujido, y luego actualizar la base de datos con otro de ida y vuelta.

Otra consideración es si la base de datos es compartida entre aplicaciones. Si es así, la lógica debe estar en la base de datos para que todos puedan utilizarlo.

Media niveles tienden a ir y venir, pero los datos permanecen para siempre.

Soy un tipo de objeto, pero me gustaría ir con cuidado.

Es un problema complicado. No creo que las declaraciones en blanco y negro trabajarán en todos los casos.

Answer 4

Bueno, como ya se ha dicho, que depende de muchos factores. Pero desde cuestionas parece que los arquitectos están proponiendo mover los procedimientos almacenados desde el interior DB para SQL dinámico dentro de la aplicación. Eso suena muy dudosa para mí. SQL es un lenguaje orientado a conjuntos y lógica de negocio que requiere el masaje de gran cantidad de registros de datos sería mejor en SQL. Piense búsqueda complicado y función de tipo de informes. En las otras ediciones de partidas individuales con la mano correspondiente validación de reglas de negocio es mucho mejor que se realiza en un lenguaje de programación. El almacenamiento en caché de los datos de cambio lento en el nivel aplicación es otra ventaja. Esto es aún mejor si usted ha dedicado servicio de nivel medio que actúa como puerta de acceso a todos los datos. Si los datos se comparten directamente entre aplicaciones dispares luego procedimiento almacenado puede ser una buena idea. También tienen que tener la disponibilidad / experiencia del talento SQL vs talento de programación en la organización. No hay realmente ninguna respuesta general a esta pregunta.