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.

Leer más...

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

Leer más...

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

Leer más...

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:

Leer más...

Que bonito es eso de que el motor de SQL haga las cosas más comunes automáticamente, ejemplo de esto pueden ser los valores calculados, un trigger o insertar un valor numérico auto incremental, los tres son muy similares.

Sin embargo esto puede causar un dolor de cabeza si no sabemos como emplearlos, a veces necesitamos usar el identificador de un registro que apenas insertamos en una tabla desde la sesión 52 en la sesión 53 del SQL o bien puede ser útil el conocer el último identificador insertado en una tabla sin tener que hacer un max sobre el campo.

Haber, tenemos IDENT_CURRENT tal como en el SQL Server 2000 SCOPE_IDENTITY y @@IDENTITY. Las tres funciones regresan el ultimo valor generado automáticamente. Peeeeroooo, tienen un alcance de sesión que se pueden definir de la siguiente manera:

• IDENT_CURRENT Regresa el último valor generado por una tabla específica en cualquier sesión y cualquier alcance(scope).
• @@IDENTITY Regresa el último valor generado por cualquier tabla en la sesión actual en todos los alcances (scope).
• SCOPE_IDENTITY Regresa el último valor generado para cualquier tabla en la sesión actual y el alcance actual (scope).

Osea, si me explican ... entiendo! Ahora si ya todo claro =).

NOTA: cuando el valor de IDENT_CURRENT es null (porque la tabla ha sido truncada o no contiene datos), la función regresa el valor de siembra (seed), esto es el valor autoincrmental.

Ahora los ejemplos, que "hermosa weba"... para que hacerlo todo? mejor reutilizo lo que está en la ayuda de MSDN :

Que se puede encontrar en http://msdn.microsoft.com/es-es/library/ms175098.aspx

Vale la pena darle un vistazo a :

• IDENT_SEED ( 'table_or_view' )
• IDENT_CURRENT ( 'table_or_view' )
• DBCC CHECKIDENT()

http://msdn.microsoft.com/es-es/library/ms176057.aspx