Iver's web place

El día de ayer tuve el gusto de dar una pequeña charla de SQL Server Integration Services (SSIS) en la Comunidad de .NET que desde hace tiempo se ha empeñado en formar el buen Raúl Guerrero.

La audiencia no tenía mucho conocimiento de la herramienta, pero si tenían experiencia en la necesidad que pretende cubrir SSIS y espero haber transmitido adecuadamente el conocimiento para que puedan sacarle provecho en el futuro como hasta ahora he tenido oportunidad de hacer en algunos proyectos.

Por cuestiones de tiempo no me fue posible quedarme a la siguiente charla que era de Creación de aplicaciones para Windows Phone

Ahora bien, para concluir con este post y compartir el material que empleamos en la charla. Se pueden descargar de las siguientes ligas:

* ETLconSSIS.pptx * SSIS_Sample.zip Espero sean útiles y cualquier comentario o sugerencia para mejorar el material es bienvenido.

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.

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

• 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.

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: