Iver's web place

En post anteriores, escribí un poco sobre los índices y los tipos de índices que hay en SQL Server 2005. Para continuar con el tema pondré un par de ejemplos para crear y borrar índices, así como identificar cuando están fragmentados y que hacer en ese caso.

Crear y borrar índices

Para saber cuando crear índices y de que tipo, es necesario entender como funcionan los tipos de índices. De forma resumida se puede decir que los índices se almacenan de dos formas, generando en la misma tabla el índice (clustered) y creando una tabla aparte donde vivirán los índices (nonclustered).

Hablando de rendimiento, si tenemos consultas que debemos realizar constantemente con cláusulas ORDER BY o GROUP BY puede servirnos de mucho el crear un índice agrupado (clustered) en el campo afectado. Los índices no agrupados (nonclustered) satisfacen mejor las consultas donde sus campos están incluidos (included) en el índice ya que accede siempre a la misma tabla (la del índice). También el usar índices no agrupados permite tener en diferente file group los índices y las tablas, agilizando el acceso al disco si tenemos cada archivo en diferente unidad.

Es importante saber que en SQL Server no es posible defragmentar una tabla, pero si podemos defragmentar un índice, lo que nos indica que si tenemos un índice agrupado, podremos defragmentar la tabla ya que es la misma donde vive el índice. Crear o eliminar índices tiene sus implicaciones, si tenemos un índice agrupado en una tabla y 4 índices no agrupados apuntando a la misma tabla, al eliminar el índice agrupado se están eliminando y creando los 4 índices no agrupados. Si creamos un índice agrupado sobre una tabla que tiene 3 índices no agrupados, en ese momento se eliminan y se crean nuevamente los índices no agrupados.

En el buzz, una amiga publico esta anécdota y como me gustó la voy a publicar aquí. =)

Rodrigo estaba haciendo fila para poder ir al aeropuerto. Cuando un taxista se acercó, lo primero que notó fue que el taxi estaba limpio y brillante. El chofer bien vestido con una camisa blanca, corbata negra y pantalones negros muy bien planchados, el taxista salio del auto dio la vuelta y le abrió la puerta trasera del taxi. Le alcanzo un cartón plastificado y le dijo: yo soy Willy, su chofer. Mientras pongo su maleta en el portaequipaje me gustaría que lea mi Misión.

Después de sentarse, Rodrigo leyó la tarjeta. Misión de Willy: Hacer llegar a mis clientes a su destino final de la manera mas rápida, segura y económica posible brindándole un ambiente amigable.


Rodrigo quedo impactado. Especialmente cuando se dio cuenta que el interior del taxi estaba igual que el exterior. ¡¡Limpio, sin una mancha!!

Ya tiene algo de tiempo que estoy inmerso en el diseño y mantenimiento de las bases de datos y ya que estoy en eso me gusta investigar y conocer mejor las herramientas con las que cuento para facilitar mi trabajo. Muchas personas toman las bases de datos a la ligera y creen que con solo emplear un ORM, generadores de código o frameworks que te agilizan[*] el desarrollo es suficiente para tener un producto de calidad.

Es un gran error y puede ser muy doloroso el proceso para aprender que las bases de datos son como tal la base de los sistemas. Sin bases de datos no hay sistemas, porque lo más importante son los datos que existen en un sistema.

Ahora bien, dentro de tantas cosas que existen en la base de datos hay unas estructuras muy importantes llamadas índices. El índice de una base de datos es una estructura de datos que mejora la velocidad de las operaciones, permitiendo un rápido acceso a los registros de una tabla. Debido a esto es necesario conocer a fondo que tanto podemos explotar los índices, en el presente post procuraré mostrar información que sea útil para este fin en SQL Server 2005:

• Tipos de índices
• Crear y borrar índices
• Identificar índices fragmentados
• Reorganizar o reconstruir índices
• Mejores prácticas

Ya que últimamente me ha dado por escribir de SQL, se me antoja escribir de un tema que desconocía cuando programaba en ASP 3.0 pero que siempre era necesario conocer. Me refiero a las "juntas en SQL" (que ojalá fueran reuniones en un bar =/ ) osea los JOIN de SQL. Que si bien es muy necesario conocer que hace exactamente cada tipo de "JOIN", es común encontrarse con "desarrolladores" que hacen uso de los "JOIN" a lo wey!

Recuerdo que varias veces pregunté (obvio a las personas equivocadas) cual era la diferencia y entre los tipos de JOIN y me decían: un INNER JOIN te sirve para obtener el resultado de dos tablas en una consulta y un CROSS JOIN un producto cartesiano de las tablas (ahora que lo analizo bien puede ser que se quisieran deshacer de mi sin explicar mucho o_O!)

OK, la respuesta no está del todo mal, sin embargo creo que primero se debe conocer cuales son:

• INNER JOIN
• LEFT OUTER JOIN (o LEFT JOIN)
• FULL OUTER JOIN
• CROSS JOIN

En casi todas las cosas que hacemos un simple detalle hace una gran diferencia, ejemplos:

• Ponerse o no desodorante.
• Poner o no poner una coma.
• Ponerle o no ponerle .... el siguiente texto a una frase =D
• Declarar una variable con un tipo de dato correcto

El caso de las bases de datos no es la excepción y en muchos casos suele traer graves consecuencias el no haber declarado una variable con el tipo de dato adecuado. Para ser más claro, si uno declara un campo de una tabla que será nvarchar en lugar de varchar, a simple vista esto no afecta porque ambos son de texto, ¿Pero que pasa si la tabla será de hechos? Osea que la tabla sea parte de un Data Warehouse y tenga miles de millones de registros y nosotros por simple weba/flojera/pereza/valemadrismo simplemente no tomamos en cuenta que tipo de dato declaramos ... y "adentro!". Después de unos meses nos damos cuenta que la tabla ocupa mucho espacio en disco.

Update: El contenido de este post aplica para SQL Server, los tipos de datos se emplean en la versión 2000, sin embargo el uso de VARCHAR(MAX) se incluye a partir de la version 2005 de SQL Server.

El problema no es solo un campo, el campo es uno de los problemas ya que cada campo está declarado como nvarchar(200). Tan solo hay que ver la diferencia entre varchar y nvarchar ... osea la "n" .. jaja >P. Veamos más a fondo el desmadre ocasionado: