Buenas, antes de nada os vuelvo a agradecer las respuestas.
seyko:
Cita: Todavia no entiendo porque no indexas la fecha?!?!
En la aplicación el usuario tiene que introducir obligatoriamente un rango de fechas (FECHADESDE, FECHAHASTA) que luego se añade a la cáusula WHERE de todas las consultas de esta manera: FECHADESDE >= :fecDesde AND FECHASTA <= :fecHasta, con lo cual en principio los índices no valdrían para nada puesto que no estoy introduciendo una serie de valores concretos. La idea de añadirlo al índice consistiría en añadir a las consultas la cláusula AND TO_CHAR(TABLA.FECHADESDE, 'YYYY') = :año, teniendo en cuenta que casi todos los registros tienen FECHADESDE = FECHAHASTA y que casi todas las consultas suelen darse para rangos de fechas de un mismo año.
Como comentaba
matanga, en principio los índices serían herramientas para satisfacer a las consultas, pero tengo comprobado que las consultas pueden optimizarse bastante si uno es capaz de clasificar y dividir por áreas los datos. Ejemplo: supongamos que cada centro de salud de todo el mundo tiene un código identificador único. El usuario tiene un menú donde desglosa país, provincia y centro de salud. Uno podría obtener la lista de todos los centros de salud seleccionados por el usuario y filtrar mediante esos códigos, pero si creamos campos e índices por país, provincia y código de centro, para los casos más habituales en los que el usuario selecciona países o provincias completas las consultas mejoraran, puesto que entramos, por ejemplo con un único código de país.
Cita: Se puede particionar por un campo fecha, es una de las practicas mas comunes del particionamiento por rangos, donde los rangos pueden ser, por ejemplo, meses años o conjunto de años.
Interesante, desafortunadamente no lo he hecho nunca y la versión de Oracle que tenemos en los entornos locales no es la Enterprise pero creo que en producción sí, podría solicitar que lo hicieran allí...
Cita: Esto es muy propio de Data warehouse, para esto Oracle implementa Materialized Views, no tiene relacion con particionamiento
No conocía lo de Materialized Views pero he estado mirando un poco y tengo la sensación de que al final consiste en algo así como tener en una tabla auxiliar el resultado de una consulta pesada que se irá actualizando cada cierto tiempo y que luego uno puede tirar de ella para obtener el resultado de inmediato (una especie de precálculo si no he entendido mal). La pega que le veo es que en el caso que nos ocupa los datos resultantes depende de varias selecciones que ha hecho el usuario, como es el rango de fechas, es decir, la media de un valor por ejemplo varía dependiendo del rango de fechas seleccionado, con lo cual no veo qué tipo de precálculo puede ayudar en este caso.
Cita: El historico, si lo implementas con particionamiento, no tiene necesidad de duplicar insert ni delete ni ninguna otra sentencia SQL
Entiendo entonces que lo ideal es seguir con la tabla maestra (contiene los datos históricos y los actuales) pero particionada por rangos de fechas y descartar la opción de crear una nueva tabla para 'valores actuales' donde están duplicados los datos de los dos últimos años.
Un saludo.