[Debate] ¿Mayor carga a la BD o a la aplicacion?

Estoy ultimando detalles con un sistemita que me encargaron para lo del IDE(see gato Visual Basic jajaa) y consultando con el DrAoyama via soporte Tecnico inmediato salio el tema: A quien cargarle el mayor trabajo¿ a la aplicacion(traer datos desde un query y hacer los calculos en la aplicacion) o a la BD(Triggers, StoredProcedure)?.

En la clase de BD me enseñaron que era mejor que ese tipo de calculos los hiciera la BD porque tardan menos las consultas, pero el DrAoyama me decia que con el tiempo esas aplicaciones se hacen pesadas y lentas.

Asi que abro el debate, en la experiencia de los clabers ¿que les ha resultado mejor y bajo que condicciones?

Concuerdo con Auyama. Actualmente el enfoque se orienta a que sea tu Servidor de Aplicaciones donde se realicen los cálculos y relegar a los SGDB labores de repositorio, almacenaje y mantenimiento.

Muchos de los frameworks web de la actualidad no incluyen ya soporte a Stored Procedures incluso.

A mí también me enseñaron a realizar ese tipo de cálculos en la BD, pero finalmente estamos hablando de lógica de negocio y de tu aplicación, y debería estar definida en el dominio de la misma.

A mi no me gusta casarme con un sistema de base de datos para realizar calculos, porque si en un futuro alguien necesita modificar los calculos se vuelve mas dificil hacerlo desde el motor de BDD.

Alguna ves desarrolle un sistema donde todos los calculos los hacia con SP de SQL server, y la empresa donde trabajaba despues de 2 años de utilizar ese sistema determino que necesitaba otra funcionalidad. Al tratar de realizar los cambios me di cuenta que no era tan facil hacerlo en el Server de BDD y me toco realizar otra ves toda la aplicación...

Bueno eso es en mi experiencia que dicho sea de paso no es tan grande.

Saludos

Personalmente hago las cosas en el server, pues no es lo mismo hacer un SELECT desde el cliente, que tenerlo compilado como una vista aya arriba, la cual tiene plan de ejecucion ,etc, etc. que permiten que tenga un rendimiento mucho mas optimo que el que tendra una consulta hecha desde un cliente, por cierto, eso es para querys complejos, pues para un select a from b no hace falta estar haciendolo aya arriba... por lo otro te cambiaron la BD, pues si, tienes que re-hacer las cosas.

Zandy escribió:

Hace poco leí un estudio sobre las ventajas de un SP sobre un query, y si bien en el primero se optimiza el árbol de consulta, una consulta sencilla, del tipo CRUD, no presentaba tanta diferencia. Esto permite que podamos trabajar ahora con ORMs que nos hagan pensar en modelos y ya no tanto en tablas.

En mi opinión, vale más tener un modelo normalizado y desnormalizado, aplicando índices correctamente, sabiendo de qué manera modificar las tablas según las consultas se hagan más complejas, que las ventajas de compilar la lógica en un SP, además de que así impedimos, como dicen anteriormente, "casarse" con una de las capas.

En un modelo tradicional de capas, hacer los cálculos desde la base de datos es horrendo. Para eso están los lenguajes del lado del servidor. Por supuesto tampoco lo debes hacer del lado del cliente, a excepción de que sean datos muy específicos. De lo contrario, tu aplicación se vuelve anti-portable y mantenerla será bastante triste.

La teoria te dice algo... la practica otra. Trabaje en un estudio contable 6 meses, te puedo asegurar que cuando hacen alguna nueva ley o nueva forma de cobrar algo NUNCA piensan en el programador que debe hacer el trabajo sucio, tenlo en cuenta.

En mi opinion, usaria algun que otro SP; siempre y cuando sean necesarios para traer datos, y algun calculo sencillo como count, sum, promedio, etc; pero esto ultimo (sumas, promedios) se contradice un poco con lo que dije arriba, las app financieras son jodidas, asi que realiza todo lo que puedas en el lado del servidor, te ahorraras dolores de cabeza.

Yo por lo general no uso SP, y no he visto disminuido la calidad/velocidad de los proyectos que he realizado.

Siempre y cuando los cálculos sean básicos puedes hacerlo en el motor de BD sin perder la portabilidad de la que hablan y tu aplicación tendrá mejor tiempo de respuesta. Ahora cálculos muy específicos si debes hacerlo en el lenguaje de servidor. Con respecto a los lenguajes de clientes, recuerden que son solo para mejorar la experiencia del usuario, no para restringirlo, cosa que olvidan muchos programadores.


saludos

Depende, depende. La verdad cada cosa para lo que es. SQL es perfecto para filtrar datos, realizar algunas operaciones con los datos. Yo suelo hacer todo lo básico con SQL. Solo para procesos complejos y con reglas de negocio que se salen de lo básico y que no se puede en SQL(o es infinitamente jodido), lo hago por code. He trabajado en proyectos muy grandes, y mientras el SQL este bien hecho, no hay problemas de rendimiento, hablo de sistemas con millones de registros.

En aplicaciones de ese tamaño, un índice mal hecho, un join hecho de manera incorrecta, un error de lógica en el SQL, provocaría que todo se joda. Por eso muchos suelen creer que trabajar directamente en el code es mas rápido que por SQL. Para grandes manejos de información, al menos en mis pruebas, nada es mas rápido que hacerlo a través de un DBMS.

La otra cosa que tambien influye mucho es que la ventaja de hacerlo en BD es que tendras integridad en los calculos, cuando una aplicacion, un producto mas bien, pasa muchos ciclos de desarrollo y calculos son dejados a diferentes instancias de la aplicación, suele suceder que cada instancia consigues un resultado distinto, digamos que tienes datos que son accedidos desde aplicaciones de escritorio y web y cada aplicacion hace los calculos en vez de hacerlos la BD, quizas en algun redondeo las aplicaciones se comportan distinto, esas son cosas a tomar en cuenta.

Igual como dice dano, depende de muchos factores, hay logicas de negocio que ya de por si es muy jodido implementar en un SQL, pero yo personalmente me inclino un poco mas hacia dejar el trabajo a las BD.

Saludos

Prozac escribió:

Para eso existen las transacciones que, si no me equivoco, son soportadas por la mayoría de lenguajes y frameworks.

Yo prefiero siempre definir las reglas de negocio y la programación en general en términos del dominio del problema.
Hacer debug a éste código, por ejemplo, es mucho más sencillo en esos términos:

Código :

class Product < ActiveRecord::Base
  has_many :input_orders
  has_many :providers, :through => :input_orders
  has_many :stores, :through => :input_orders
  
  validates_presence_of :name, :on => :create, :message => "debe tener un valor"
  validates_presence_of :stock, :on => :create, :message => "debe tener un valor"
  validates_numericality_of :stock, :on => :create, :message => "no es un número"
  validates_uniqueness_of :additional_code, :on => :create, :message => "debe ser único"
end

En términos de performance, no hay demasiados problemas si se tiene un buen diseño de BD. Finalmente los SGDBs están preparados también para hacer automatizaciones a queries sencillos.

Pero creo que es un tema que linda también con la experiencia personal y expertise en el tema. No necesariamente un enfoque será mejor que otro.

yo recuerdo hace unos años cuando usaba VB6, hice una consulta con varios JOIN , era un sistema de control de cursos y notas. La consulta me devolvía un listado de alumnos con sus notas de un determinado curso y aula, con una consulta cruzada, una bonita experiencia .
Al inicio lo hice desde el aplicativo pero se demoraba casi 10 segundos en arrojar los resultados (en un servidor local), mientras que por un SP fue más rápido, solo 2 o 3 segundos.

Pero como bien mencionan todo es cosa de manejar bien los indices u otra forma.
Aquí un ejem con Categorías muy bueno:
http://dev.mysql.com/tech-resources/articles/hierarchical-data.html
( Este enlace estaba dentro del Foro del CMS Clabiolo ).

Opino que según la experiencia y los conocimientos de cada uno escoger la mejor lógica para crear los procesos en la BD o en el aplicativo, pero evitando en lo posible no tener todos en la BD.

La verdad no se si comentar aca... podría estar revelando importantes Trade Secrets.

Bueno, muy por encima, ocultando detalles importantes, con dos aplicaciones que hice yo:
En una aplicación todos los cálculos se hacen por base de datos. Absolutamente todos. Es un caso particular donde se requiere flexibilidad absoluta, y hacerlos en un lenguaje interpretado sería dolorosamente lento. La base de datos es mas rápida que el lenguaje interpretado. Las consultas en este son brutalmente complejas, de 40 o 50 líneas con muchos joins y subconsultas.

En otra aplicación los cálculos se realizan sólo por la aplicación, la base de datos es para almacenamiento. En esta otra aplicación el desempeño es fundamental, y la parte que realiza los cálculos de la aplicación está escrita en C++. Las consultas en este son simples SELECT e INSERT.

Así que la respuesta es: DEPENDE

Shorel escribió:

Exacto, totalmente de acuerdo. Lo interesante es que muchas de las aplicaciones web actuales suelen ser del segundo grupo.

Shorel escribió:

De acuerdo, que de hecho fue lo que dije en un principio:

Dano escribió:

Tu aplicación, debe tener un poco de cada cosa,

los metodos procedural, no sobrecargan la base de datos, mientras sepas el uso adecuado que tienes que darle, simplemente, evitas el mal uso de exesivos Querys, y proteges la informacion y las tablas a las cuales estas accesando si hablamos de una pagina web, ciertamente ocultar esta informacion es esencial por eso se usan los procedurals a nivel de servidor, si tienes una aplicacion normal no orientada a web, esta puede funcionar sin triggers efectivamente, mi recomendacion, es toma un poco de cada cosa y crea el balance perfecto,
cuando hablamos de programacion no hay reglas establecidas, puedes hacer practicamente lo que quieras, eso si segun lo que te han enseñado puedes tener en cuenta,

1) el tipo de aplicacion que estas haciendo (web / aplicacion de escritorio ) tienes (trigger, javascrip a nivel cliente / Full Querys )

Solo si son aplicaciones muy grandes, el uso de procedurals debe ser medido si es un servidor dedicado, lo que te va a llevar al exito, son las pruebas, hay es como puedes observas las fallas y las debilidades de tu diseño.