Estoy haciendo recopilación de post antiguos de mis ex-blogs, que creo que pueden merecer la pena. Y uno de ellos es este. ¿Que criterios debo de seguir para crear índices a tablas en Oracle?. Leed atentos:
He aquí la pregunta que muchos se hacen cuando se encuentran con problemas de rendimiento en sus tablas.... ¿he de crear un índice?. Veamos en que criterios podemos basarnos.

Como norma general, para cualquier tipo de índice, debe limitarse el número de estos y crear siempre los que exclusivamente sean necesarios, es decir, el menor número posible dentro de todos los que hagan falta.

La selectividad de un índice es la relación entre el número de valores distintos de una columna indexada y el número de registros de la tabla. Si una tabla tiene 1000 registros, y una columna indexada de la tabla tiene 950 valores diferentes, la selectividad del índice es 0.95 (950/1000). La mejor selectividad es 1. Los índices únicos sobre columnas no nulas y las claves primarias siempre tienen selectividad 1.

La selectividad de un índice nos da una medida de su utilidad para evitar I/O en la ejecución de sentencias contra la tabla. Si un índice sobre una tabla de 1000 registros tiene sólo 5 valores diferentes, entonces su selectividad es muy pobre (5/1000 = 0.005). Para cada posible valor de este índice, habrá un promedio teórico de 200 filas. En este caso, podría ser más interesante realizar un full table scan en vez de acceder vía índice a esta tabla, si bien se debe comprobar con datos reales de acceso a la misma.

Si se está usando CBO, el optimizador no realizará accesos a tablas a través de índices con una selectividad muy baja.

Puede sin embargo ser conveniente usar índices con baja selectividad, si se cumplen varias condiciones.

• Las sentencias empleadas no usan variables bind o se ha implementado algún mecanismo para distinguir aquellas consultas que deben emplear el índice, como por ejemplo, uso de literales, basándose en la distribución de datos.
• El índice está analizado con histogramas.
• El valor usado en las condiciones tiene muy poca cardinalidad.

En la vida del desarrollo del software siempre se planetan varios problemas de difícil o, al menos, complicada solución. Por este motivo durante las últimas décadas se han estado estudiando y poniendo al dia diferentes metodologías, con la itención de resolver todos estos problemas.

  - Problema 1: Modelo de gestión del proyecto.
         El primer problema que suele surgir es como gestionar el proyecto para que este sea desarrollado con más agilidad y menor esfuerzo. Los principales problemas con los que se han enfrentado hasta ahora los analistas para gestionar los proyectos eran el cumplimiento de fechas y la adaptación a nuevos requerimientos durante el desarrollo de la aplicación, derivado del ciclo tradicional de vida del software. Por eso se desarrollaron lo que más tarde se han conocido como "metodologías ágiles de desarrollo", de las cuales han destacado Scrum  y Extrem Programing.
Desde el inicio, la que mejores resultados parece heber mostado ha sido la metodología Scrum que básicamente consite en: "un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto." La siguiente ficha explica perfectamente el proceso:

  -  Problema 2: Modelado del software.
         Otro de los grandes problemas es elegir una tecnología adecuada a las necesidades funcionales de la aplicación. Esto se solucionó en parte, con la popularización de las aplicaciones web, cuyos frameworks han implementado, de forma estandarizada, el modelo Vista-Controlador como parte integral del sistema, de tal manera que se permite de una manera sencilla la programación de aplicaciones complejas. Un ejemplo claro de este modelo, lo representa el modelo para java llamado "Structs".

         Para tener más información sobre los modelos del software, lo mejor es recurrir a los "Pattern Dessign", cuyo nacimiento surgión con el conocido como Gang of Fours, ya que sus autores fueron  Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. El manual se divide en dos partes, los primeros dos capítulos, que exploran las ventajes y dificultades de la programación orientada a objetos, y el resto, que describen un conjunto de patrones de diseño software. Se incluyen ejemplos en C++ y Smalltalk.

Como recomendación, visitad todos los links expuestos en el artículo, para una mayor pofundización sobre el tema.