Vamos al punto: Mis palabras fueron
Cita: almacén de datos con funciones específicas
Tal vez el error, para su mejor comprensión es qa qué me refería con "funciones específicas", cosa que incluye los store procedures, functions, triggers, restricciones, sentencias DCL, sentencias DDL, y un amplio grupo de cosas que conocemos todos los que estamos en este asunto.
Simplemente no quería entrar en detalles.
Por otro lado, las funciones agregadas tienen uso estadístico y matemático, necesarias para la resolución de consultas. Si se almacenan o no los resultados depende de cierto tipo de consideraciones tales como la generación de cubos y reportes, donde sí e almacena información ya consolidada. De modo que cierta desnormalización es posible por razones de eficiencia para el usuario.
Que los SP recargan la tarea en ciertos niveles, es cierto, si realizamos un testeo de performance de ciertos SP, hemos de descubrir que algunos de ellos son ineficientes comparados contra una consulta compleja (me ha sucedido en varias ocasiones), por lo que finalmente es mejor desecharlos, pero
a priori no se puede decir que todos
recargen a la base. Hay que ver de
qué SP estamos hablando, en
qué base y con
qué datos.
Sobre que los SP pueden disminuir la carga de trafico entre el cliente y el servidor, eso es cierto pero sólo bajo un criterio: cuando la tarea se realice off-line. Si usas SP para tareas en que el cliente (la aplicación) espera respuesta o resultado, generas una sobrecarga de tráfico hasta que la tarea del SP se termine y los resultados retornen.
Además, debes considerar que si se realizarán UPDATE, DELETE o INSERT dentro del SP, estos requieren transacciones y bloqueos de tablas que no se liberan hasta que el SP no lo hace..., por lo que los SP aumentan el riesgo de deadlocks si no están bien programados y las tareas son largas.
Aún con todas estas cosas, son uno de los medios más eficientes para realizar tareas que no se resuelven con un SELECT * FROM...