Diseño de Base de Datos, parte XVIII: SQL Semiavanzado. Índices

El día de hoy empezaremos la sección semiavanzada de SQL. Será una breve introducción a algunas de las instrucciones y cosas que podemos hacer con este lenguaje. Esperemos que estos breves recursos les sean de utilidad para el futuro. ¡Saludos!

INDEX

Los índices nos ayudan a obtener datos de las tablas en forma más rápida. Utilicemos un ejemplo para ilustrar este punto:
A very good analogy is to think of a database index as an index in a book. If you have a book about dogs and you are looking for the section on Golden Retrievers, then why would you flip through the entire book – which is the equivalent of a full table scan in database terminology – when you can just go to the index at the back of the book, which will tell you the exact pages where you can find information on Golden Retrievers. Similarly, as a book index contains a page number, a database index contains a pointer to the row containing the value that you are searching for in your SQL.
46. What is a good analogy for a database index?, en SQL Performance Tuning Interview Questions
El mismo principio se aplica para la obtención de datos desde una tabla de base de datos. Sin un índice, el sistema de base de datos lee a través de toda la tabla (este proceso se denomina “escaneo de tabla”) para localizar la información deseada. Con el índice correcto en su lugar, el sistema de base de datos puede entonces primero dirigirse al índice para encontrar de dónde obtener los datos, y luego dirigirse a dichas ubicaciones para obtener los datos necesarios. Esto es mucho más rápido.

Por lo tanto, generalmente se recomienda crear índices en tablas.

Sintaxis:

¿Cuándo no usar índices?
  • No deben ser usados en pequeñas tablas
  • Tampoco deben ser usados en tablas que frecuentemente tiene operaciones de actualización e inserción
  • Mucho menos en columnas que contengan una gran cantidad de valores NULL
  • Y por último, no usarlos en columnas que son constantemente manipuladas.
Los índices ocupan mucho espacio en disco, y pueden causar que las operaciones de INSERT, UPDATE y DELETE se alenten, dado que no solamente se está actualizando la información de la base de datos, sino que también es necesario actualizar los índices.

Como regla general, un índice debe ser solamente creado cuando la tabla contiene información en la columna indexada que será consultada frecuentemente.

Existen dos tipos de índices: CLUSTERED y NON CLUSTERED. Veamos:
  • Campos autoincrementales (IDENTITY, NEWSEQUENTIALID, etcétera), deben convenientemente ser del tipo CLUSTERED INDEX.
  • Los CLUSTERED INDEX son convenientes si se va seleccionar un rango de valores, ordenar (ORDER BY) o agrupar (GROUP BY).
  • La PRIMARY KEY es un buen candidato para un CLUSTERED INDEX, pero no siempre. Por ejemplo, si tenemos una tabla de ventas, cuya llave primaria es un IDENTITY en donde se efectúan muchas consultas por rangos de fecha, el campo Fecha seria un mejor candidato para el CLUSTERED que la llave primaria.
  • Para búsquedas de valores específicos, conviene utilizar un NON-CLUSTERED INDEX.
  • Para índices compuestos, mejor utilizar NON-CLUSTERED INDEX (generalmente).
Ejemplo:

¡NOTA! No uses los términos índice y llave de manera intercambiable (aunque algunos autores así lo ven). Un índice es un mecanismo físico (relacionado al hardware) que la base de datos emplea para mejorar el rendimiento. Una llave es un concepto lógico (basado en la información) que emplea la base de datos para hacer cumplir una integridad referencial y actualizar a través de vistas.

Como buena lectura, te recomiendo leer el capítulo 12 del libro SQL: Visual Quickstart Guide, de Fehily, viene incluido en la bibliografía, que trata el tema de los índices.

Bibliografía.-

Libros.-
    Fehily, C. (2005). SQL: Visual Quickstart Guide, Third Edition. Peachpit Press.
Web.-
Otros.-
  • Curso SQL de Nectri

Comentarios

Entradas populares