Open DBDiff (Otro SQL Schema Compare mas, pero Open Source)

Muchas veces quienes trabajan y desarrollan con bases de datos, tendrán el problema de tener que ver como sincronizar los cambios en la base de datos de desarrollo con la de producción o testing. Es realmente un tema, ya que cualquier error ahí, nos hace fallar la subida al ambiente de producción (o de testing).Existen montón de herramientas que permiten sincronizar 2 base de datos y generar un script de migración de una base a otra, ahorrándonos el trabajo de nosotros tener que llevar un tracking de los cambios, lo cual lleva a una minimización de error. Una excelente herramienta para hacer esto es el Red Gate Compare, la cual es bastante potente y rápida. Lástima que sale 395 USD en su versión más económica. También Visual Studio for Database Professional incorpora una herramienta similar. Pero es necesario tener la versión Team System (la más cara) del VS (2005/2008).

Por lo tanto, he decido crear una herramienta 100% open source, desarrollada en C# usando .NET 3.5, para comparar 2 bases de datos y generar un script de diferencias.

La herramienta se llama Open DbDiff, actualmente está en estado Beta y solo funciona para SQL Server 2005, pero la hemos probado con montón de distintos casos de uso diferentes, en las más variadas situaciones y ha funcionado muy bien. Es rápida, especialmente en maquinas con más de un núcleo, ya que es multihilo. Su algoritmo de generación de script es bastante inteligente y sabe en qué situaciones debe regenerar una tabla o índice, o hacer simplemente un ALTER.

Compara los siguientes objetos:

• Tablas (incluyendo opciones como vardecimal, text in row, etc..)
• Columnas (incluyendo campos Formulas, opciones de xml, collate, etc..)
• Constraints
• Indices
• Triggers
• User Data Types
• Vistas
• Store Procedures
• XML Schemas
• Sinonimos
• File Groups
• Assemblys

De todas maneras, toda le falta pulir algunos detalles, está en estado Beta, pero es muy potente. Si está buscando herramientas de sincronización, se las recomiendo. El link para bajar el instalador es el siguiente:

http://opendbiff.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=25206

Diferencias entre Clustered y Non Clustered Index en SQL Server

Una pregunta muy común para los iniciados en el mundo de SQL Server, es cuál es la diferencia entre un índice clustered y un índice non-clustered y en qué caso conviene usar un índice u otro. Bueno, empecemos a describir las características generales de un índice y luego de estos tipos de índices y las conclusiones van a ser evidentes.

Los índices son objetos de la bases de datos, cuya función es optimizar el acceso a datos. A medida que las tablas se van haciendo más grandes y se desea hacer consultar sobre estas tablas, los índices son indispensables.

Internamente un índice normal es una estructura de árbol, que cuenta con una página principal y luego esta con paginas hijas, que a su vez tiene más paginas hijas hasta llegar a la pagina final del índice (leaf level).

La clave del índice está repartida en las páginas del índice, de modo tal que la búsqueda se haga leyendo la menor cantidad posible de datos.

Estructura interna de un índice:

Después de esta brevísima introducción, donde está la diferencia entre un índice clustered y uno non-clustered? En la leaf level (la ultima pagina) del índice. En un índice non-clustered, la clave por la que buscamos tiene un puntero a la página de datos donde se encuentra el registro. Mientras que en índice clustered, la leaf level es la pagina de datos!. Con lo cual, el SQL Server, se ahorra hacer un salto para leer los datos del registro (Bookmark lookup). La diferencia es importante, ya que el uso de este tipo de índices al evitar tener que hacer lecturas adicionales para traer el registro, son más performantes.

Búsqueda por clustered index:

Búsqueda por non-clustered index:

SQL Server 2005 incorpora una nueva feature interesante en los índices non-clustered. Ahora es posible incluir dentro de la leaf page del índice, campos que en sí, no son parte de la clave. Esto nos permitirá en algunos casos, evitar el salto a la página de datos (Bookmark Lookup) que habíamos hablado anteriormente. Aunque hay que tener cuidado de seleccionar bien que campos se desean incluir al índice, porque de poner demasiados se expandería mucho el índice, haciendo ineficiente. Por ejemplo, si tenemos una tabla Personas cuyo campo DNI es un índice non-clustered y queremos hacer una consulta que solo traiga el Apellido y DNI, entonces si incluimos el campo Apellido , nos ahorraríamos tener que ir a la página de datos para buscar el valor. Es importante recalcar que el campo Apellido no sería parte de la tabla, sino un campo mas en pagina final del índice.

Ahora bien, entonces porque no siempre usar índices clustered? Bueno, en primer lugar, lamentablemente solo puede haber 1 solo índice clustered por tabla. La razón es muy sencilla y lógica: Los registros de la tabla físicamente son las paginas leaf-level del índice clustered. Los datos de la tabla esta ordenados según el índice. Y obviamente una tabla no puede simultáneamente estar físicamente ordenada de 2 maneras diferentes.
Por lo tanto, en tablas grandes y muy consultadas, tenemos que ser cuidadosos y analizar a que campos vamos a seleccionar para ser llaves del índice clustered. Tenemos 1 solo índice de este tipo por tabla, no hay que desperdiciarlo!!!
Este último punto es importante para saber en qué situaciones y para que campos se debe utilizar un clustered index o un non-clustered.

Guía general de uso de índices:

• Campos autoincrementales (Identitys, newsequentialid, etc), deben convenientemente ser del tipo clustered index. La razón es reducir el page split (fragmentación) de la tabla.
• Los clustered index son convenientes si se va seleccionar un rango de valores, ordenar (ORDER BY) o agrupar (GROUP BY).
• La PK es un buen candidato para un clustered index. Pero no siempre. Por ejemplo, si tenemos una tabla de ventas, cuya PK es un identity en donde se efectúan muchas consultar por rangos de fecha, el campo Fecha seria un mejor candidato para el clustered que la PK.
• Para búsquedas de valores específicos, conviene utilizar un non-clustered index.
• Para índices compuestos, mejor utilizar non-clustered index (generalmente).

Add-In Property Generator para Visual Studio

En mis épocas de programador en Java, usaba el Eclipse. Este excelente IDE, tenía una opción de refactoring que se usa para generar todos los getters y setters de una clase a partir de las variables privadas declaradas en la misma. Lo que en Java se llama getters/setters, en C# o VB sería el equivalente a las propiedades de una clase.

Siempre extrañé esa funcionalidad en Visual Studio. Cuando tenemos clases de 15 o más propiedades, tomarse el trabajo de generar 1 x 1, es aburrido.

Por lo tanto señores, he decidido hacerme mi propio Add-in de refactoring para agregarle esta interesante opción al Visual Studio. Este Add-in que desarrollé es compatible tanto con el Visual Studio 2005 como 2008. He visto un viejo Add-in, que se llama VsPropertyGenerator, que hace más o menos lo mismo, pero no tiene soporte y a mí no me funcionó y además, el que desarrolle yo, considero que es más fácil de usar.

Es libre, gratuito, pueden copiarlo, piratearlo y más que nada, disfrutarlo. El link para bajarlo es el siguiente:

http://www.opendbdiff.com/Addins.rar

Las opciones para instarlo se encuentran dentro de un archivo .txt. Cualquier sugerencia, problema o duda, dejen un comentario aquí, que prometo contestar.