Aprendiendo SQL Server

Hola a todos: En esta ocasión, vamos a ocupar esta nueva entrada en el blog para hablaros de un comportamiento inusual de SQL Server, que ejecuta ciertas funciones en cláusulas de sentencias CASE que no se evalúan a verdadero. El operador CASE CASE, tal y como nos lo decribe la MSDN "evalúa una lista de condiciones y devuelve una de las varias expresiones de resultado posibles". Es decir, nos permite retornar un valor distinto en función de cada uno de los valores posibles que pueda tener el argumento o condición que estemos evaluando. Podemos decirle que nos devuelva un resultado diferente en función del valor de una variable o de expresiones lógicas.

Imaginemos que queremos obtener el valor máximo de una columna de una tabla que puede contener valores nulos y que, en caso de no existir ningún valor en ella o ser todos los existentes nulos, deseamos obtener un cero.

En esta entrada pretendemos explicar los diferentes resultados obtenidos por distintas construcciones de consultas que, aparentemente, deberían producir el mismo conjunto de resultados. Así, veremos las diferencias entre filtrar los resultados de una query en la unión (Join) mediante condiciones ON y mediante cláusulas WHERE.

Seguramente, muchos de vosotros habréis usado en innumerables ocasiones la función de T-SQL COUNT , que no hace sino devolver un número de registros: de una tabla, de un conjunto de resultados, etc... En una de sus aplicaciones, combinado con el DISTINCT -uno de los dos argumentos que admite- COUNT nos devuelve el número de valores únicos no nulos de la tabla o conjunto de resultados que estemos consultando. Pero ¡ojo! Cuidado con la sintaxis , o podemos obtener el valor equivocado sin darnos cuenta. No es lo mismo: SELECT COUNT (DISTINCT NombreCampo) FROM NombreTabla que: SELECT COUNT(*), DISTINCT NombreCampo FROM NombreTabla

En la versión 2005 de Microsoft SQL Server, dábamos la bienvenida al nuevo tipo de datos XML . Éste nos prometía un sinfín de comodidades y ventajas en el uso y almacenamiento de XMLs en nuestras bases de datos. Así, haciendo un uso correcto de los mismos, podríamos tener nuestra información con estructuras heterogéneas almacenada en este markup language tan popular, sin engorrosas conversiones a cadenas o datos binarios. A su vez, SQL Server nos proveía con una serie de métodos y facilidades que daban un importante soporte al nuevo tipo de datos. Sin embargo, algunos ya nos hemos topado con una limitación -no resuelta en SQL Server 2008- con el tipo de datos XML: Sólo soporta hasta 128 niveles de profundidad en los nodos del XML que almacena. Sí, son muchos, pero no deja de ser un límite. Y un límite alcanzable. Ha ocurrido, ocurre, y ocurrirá.

Antes que nada, permitidme presentar este nuevo blog en el que un programador cualquiera, de una empresa cualquiera, tratará de contaros el día a día de sus peripecias con Microsoft SQL Server . Como dicen que la experiencia es un grado y que de los errores se aprende, intentaré desde estas líneas que l@s mí@s puedan serviros cuando os veáis en las mismas diatribas que me han llevado a escribir estas líneas. Sin más, allá vamos. Entre las muchas instrucciones de configuración que nos ofrece Microsoft SQL Server, hay una cuyo uso no parece aportar demasiado, pero que es vital si no queréis enfrentaros a "fenómenos paranormales" en algunas de vuestras queries. Se trata de SET NOCOUNT ON