Aprendiendo SQL Server

Entre las múltiples funciones de agregado que nos ofrece SQL Server, nos encontramos con dos que, probablemente junto con COUNT (), son las más usadas: SUM () y AVG (). El resultado que producen ambas parece bastante obvio: SUM() devuelve la suma de valores de la columna que le indiquemos a la función, mientras que AVG() nos devolverá el valor promedio de los datos de la columna deseada. Así pues, si tenemos una tabla de pedidos con la columna Importe, que indica el importe final de cada pedido sin decimales (tipo de datos int), si queremos saber la suma de los importes de todos los pedidos, bastará con realizar la siguiente consulta: SELECT SUM(Importe) FROM dbo.Pedidos; Análogamente, si queremos conocer el valor promedio de los pedidos: SELECT AVG(Importe) FROM dbo.Pedidos; El resultado devuelto por ambas será un entero (int) con la suma y el promedio respectivamente. "Estos números son muy grandes, no sé contar tanto" Estas funciones probabl...

Hace ya algún tiempo contábamos en otra entrada de este blog la importancia que tiene nombrar correctamente a los objetos de una base de datos a la hora de realizar las consultas: siempre debemos usar el formato esquema.nombre . Los motivos quedaban claros entonces: evitar problemas de rendimiento en la compilación de las consultas debidos al proceso de resolución de nombres y evitar errores si el esquema por defecto de un usuario es distinto a "dbo" o "NULL". Si bien estos errores pueden ocasionar algún quebradero de cabeza, su resolución es bastante sencilla, tal y como se explica en el artículo anterior. Sin embargo, añadimos ahora un nuevo caso que podría ser más problemático, ya que podemos generar un error que pasase inadvertido, devolviendo registros incorrectos en nuestras consultas . Cuando trabajamos con más de un esquema -cosa que deberíamos hacer no sólo por motivos de organización de nuestros objetos, sino también para aplicar permisos sobre e...

SQL Server ofrece el operador UNION para, según la MSDN , " combinar los resultados de dos o más consultas en un solo conjunto de resultados que incluye todas las filas que pertenecen a las consultas de la unión." Para que el motor de base de datos pueda combinar el resultado de distintas consultas, éstas deben respetar el número y orden de las columnas implicadas. Asimismo, las columnas equivalentes en posición deben serlo también compatibles en tipos de datos. El operador UNION presenta un modificador o argumento: ALL . Éste se escribe a continuación de UNION, así: UNION ALL. Cuando se especifica, SQL Server devuelve todas las filas de todas las consultas combinadas, incluyendo posibles duplicados. Ahí radica justamente la diferencia entre UNION y UNION ALL : El operador de unión elimina las filas duplicadas cuando combina los resultados de las consultas implicadas. Sin embargo, con el argumento ALL, los duplicados se mantienen . ¿Cuándo uso UNION y cuándo UNI...

En ocasiones necesitamos conocer quién es el propietario de una base de datos . Normalmente podemos acceder a esta información a través del SQL Server Management Studio , consultando las propiedades de la base de datos. Para ello, buscamos la base de datos que queramos consultar en el árbol de bases de datos del Object Explorer y hacemos clic derecho sobre ella. A continuación, elegimos la última opción del menú contextual que nos aparece: Propiedades . Veremos esta ventana: Propiedades de una base de datos, que incluyen el propietario (en amarillo) Sin embargo, en ocasiones no tenemos acceso a esta ventana de propiedades o, simplemente, queremos consultar el propietario de todas las bases de datos de un servidor. Para ello disponemos del siguiente script T-SQL , que nos proporcionará la información deseada: La primera columna nos dirá el propietario de la base de datos (en concreto, su login o nombre de usuario). A partir de este script , podemos filtrar por base de dat...

Volvemos de Barcelona con la sensación de haber sido partícipes de una experiencia enriquecedora: el primer SQL Saturday celebrado en España ha sido todo un éxito. La encomiable labor organizativa del grupo PASS España -encabezados por Rubén Pertusa -, la generosidad a la hora de compartir su conocimiento de los expertos venidos de diversos países para realizar sus excelentes ponencias y el entusiasmo de todos los profesionales registrados, allí reunidos durante más de 10 horas de sesiones , con un gran afán por compartir y aprender han hecho del SQL Saturday Barcelona un evento del que salimos con un bagaje positivo y muchas ganas de repetir . Como bien expuso Fernando G. Guerrero , CEO de SolidQ -uno de los sponsors del evento-, "la curiosidad es lo que nos mueve" . El apetito por aprender, las ganas de compartir experiencias y conocer a quienes también las viven son el motor de los SQL Saturday. Nada más acertado que el lema de "Share what you know, le...

El portal xkcd publica esta viñeta sobre inyección de código en SQL Server : Los peligros de llamar a tu hijo DROP TABLE Tratado con gran sentido del humor , esta cómica situación nos pone en alerta frente a la inyección de código SQL Server , que puede suponer una vulnerabilidad seria para nuestras bases de datos. Una aplicación que no compruebe los datos que en ella se introducen a través de aplicaciones externas está expuesta al desastre . En el cómic se introduce una instrucción DROP TABLE en medio del supuesto nombre de un niño inscrito en un colegio. Al introducir el falso nombre en el sistema informático del centro, el resultado es catastrófico: la tabla de estudiantes es eliminada por completo . La Wikipedia presenta un ejemplo similar para demostrar en qué consiste la inyección SQL Server, así como diversas soluciones a adoptar, dependiendo del lenguaje de programación de la aplicación: "Por ejemplo, asumiendo que el siguiente código reside en una  aplicac...

¡Por primera vez llegan a España los famosos eventos SQLSaturday ! Será en Barcelona , el próximo sábado 25 de octubre de 2014. Ya me he registrado en el evento. Será una buena oportunidad para conocer a otros profesionales de SQL Server y compartir experiencias y conocimiento, todo ello mientras aprendemos de los mejores expertos, incluidos algunos MVP y MCM de Microsoft, en las diferentes sesiones programadas. @jaimeml is attending SQLSaturday #338 - Barcelona 2014 #sqlsatBarcelona — PASS SQLSaturday (@sqlsat) junio 28, 2014 SQLSaturday es un evento gratuito de un día de duración para profesionales y futuros profesionales relacionados con SQL Server, Big Data y Business Intelligence; organizado por la Asociación de Profesionales de SQL Server (PASS) . Se han celebrado más de 300 eventos SQLSaturday alrededor de todo el mundo (el de Barcelona será el 338) y ésta va a ser la primera edición en España. El plazo de registro lleva abierto algunos días, en los que ya se han ...

La MSDN nos explica cual es la forma correcta de referenciar a los objetos en tus consultas, y es la siguiente: Esquema.Nombre ¿Por qué? Hay diversos motivos y, aunque parezca algo trivial, pueden evitarnos acceder a objetos incorrectos, errores en consultas para usuarios de la base de datos distintos al que creó el objeto e incluso problemas de rendimiento . Resolución de nombres Cuando ejecutamos una consulta, el servidor SQL realiza un proceso llamado resolución de nombres ( name resolution , en inglés) para identificar los objetos referidos en ella. Si identificamos cada objeto por su nombre completo ( fully qualified name ) , SQL sabrá determinar inmediatamente a qué objeto nos referimos y si existe o no. Por el contrario, si solamente especificamos su nombre, el motor de bases de datos tendrá que determinar a qué objeto nos referimos . Para ello usará el default schema del usuario conectado. Esquema por defecto o Default schema Cada usuario de una base de d...

Si necesitas diagnosticar problemas de rendimiento , encontrar consultas conflictivas o simplemente quieras trazar las consultas que hace una aplicación contra la base de datos, seguramente estés acostumbrado a usar el SQL Server Profiler , la herramienta que principalmente hemos utilizado para realizar este tipo de diagnósticos sobre nuestras bases de datos y servidores. También es posible que te hayas decidido a dar el paso a Extended Events , pero esa es otra cuestión. Si el Profiler es tu herramienta, muy seguramente la eches de menos en el caso de que el diagnóstico tengas que hacerlo sobre un SQL Server Express . La edición gratuita del motor de bases de datos relacionales de Microsoft no incluye esta aplicación. Es un contratiempo, pero hay alternativas . A continuación, os las presentamos: ExpressProfiler ExpressProfiler   es un ejecutable, gratuito , de código abierto, anteriormente conocido como SqlExpress Profiler. Presenta una interfaz muy sencilla en un ejecuta...

Definición En SQL Server las tablas pueden tener o no tener un índice clustered . El índice clustered es por el que SQL ordena físicamente los datos (las filas de las tablas) en disco. El índice clustered le sirve a SQL para buscar, ordenar y agrupar registros de manera eficiente. Así, no tener un índice clustered en una tabla puede llevarnos a problemas de rendimiento . Cuando una tabla no tiene índice clustered , se llama heap . El problema Los heaps  mantienen los registros en las páginas de datos en el mismo orden en el que se han insertado. Esto hace que los heaps  resulten más rápidos a la hora de realizar un INSERT, ya que no han de insertarse en una posición en concreto, sino directamente a continuación del último registro existente para la tabla en cuestión. Sin embargo, cualquier otra operación que requiera un orden en los datos será más lenta . Esto se aplica a SELECT, DELETE y UPDATE, salvo que se quieran efectuar estas operaciones sobre la ta...

En ocasiones necesitamos que nuestras consultas devuelvan valores constantes. Por ejemplo, de manera muy sencilla, podemos tener una consulta como la siguiente: Si necesitamos recuperar los valores devueltos por la consulta en un recordset de ADO.NET, por ejemplo, ¿qué tipo de datos debemos esperar de columnas de este tipo? La respuesta: depende. Depende del tipo de constante que hayamos introducido. Si se trata de un número que no desborde los 4 bytes de capacidad de un entero ( int ), como en el caso del 1 de nuestra consulta anterior, éste será el tipo de datos de dicha constante. Si escribimos la constante entre comillas simples, SQL lo tratará como un varchar del tamaño del literal que hayamos escrito. Por ejemplo: Creará un campo varchar(1). Éste sería nvarchar(2) si hubiésemos escrito lo siguiente, indicando un literal Unicode mediante la N delante del literal: Para un número con parte decimal, el tipo de datos será numeric ; lo mismo que para un número de tam...

Resumen: En cada país, en cada idioma, en cada región... usamos un formato diferente para representar las fechas. SQL Server permite comparar columnas que almacenan fechas contra cadenas de textos que convierte internamente al tipo de datos necesario. Sin embargo, según la configuración regional del servidor, la misma cadena puede ser interpretada de diferentes formas, generando errores que incluso pueden pasar inadvertidos. Para solucionarlo existe un formato de fecha estándar e independiente de cualquier configuración que hay que usar siempre: 'yyyymmdd'.

La propiedad Identity sobre una columna de una tabla de la base de datos, hace que en ésta sus valores se generen secuencialmente, a partir de una raíz, para cada registro que insertemos en ella. Las columnas identity son de tipo numérico, generalmente entero, quedando los tipos de datos que soportan dicha propiedad los siguientes: tinyint, smallint, int, bigint, decimal(p,0), o numeric(p,0) . Identity supone una gran ayuda para generar claves sobre tablas. Sus ventajas son, principalmente, que es SQL Server quien se encarga de rellenar su valor y que jamás se va a repetir el valor de la misma, ya que SQL Server genera el siguiente valor disponible para cada registro insertado. Esto evita problemas de concurrencia . Es muy típico en las aplicaciones obtener el máximo valor de la columna clave, sumarle 1 e insertar el siguiente registro. Este mecanismo no presenta ningún problema si somos el único usuario conectado a la base de datos. Sin embargo, en cuanto haya dos usuarios con...

En algunas ocasiones, buscando problemas de rendimiento en bases de datos, nos enfrentamos a una lista de consultas que son las causantes de dichos problemas. Una vez obtenida esa lista de consultas, el problema a resolver es: ¿ Dónde están codificadas esas consultas ? ¿Forman parte del código de nuestra aplicación o, por el contrario, su código T-SQL está en alguno de nuestros objetos de la base de datos; véase un trigger, un procedimiento almacenado, una función o una vista? Si se da el segundo caso, y no somos capaces de reconocer el objeto que está ejecutando la consulta que buscamos, disponemos de una vista de sistema (entre las vistas de objetos del catálogo) que nos ayudará a encontrar dónde se esconde: sys.sql_modules . Así, una consulta como la siguiente es la que necesitamos para encontrar el código: * Si tu versión de SQL Server es anterior a SQL Server 2005, hay que usar la tabla de sistema sys.syscomments .

Revisando recientemente la programación de algunos triggers , se han detectado algunos errores que se suelen cometer cuando se desconoce la idiosincrasia de estos objetos y sus tablas especiales inserted y deleted .

Los procedimientos almacenados de SQL Server pueden devolver valores bien sea a través de su valor de retorno, bien sea mediante los denominados parámetros OUTPUT . Ahora bien, para que un procedimiento almacenado nos devuelva el valor de un parámetro OUPUT deberemos tener en cuenta dos cosas : que sea declarado como OUTPUT en el propio procedimiento y que en la ejecución del mismo se especifique la palabra clave OUPUT junto al parámetro en el que queremos que se nos devuelva el valor.

Ejecutando un procedimiento almacenado que, a su vez llamaba a un método en un assembly instalado en el CLR de SQL Server, obtenía un error inesperado. El error me decía que una de las instrucciones SQL ejecutadas dentro del assembly estaba fallando. Sin embargo, si omitía el procesamiento del error, me daba cuenta de que la sentencia se había ejecutado correctamente.

Microsoft publica en la MSDN la " Lista de características desusadas del motor de base de datos de SQL Server 2012 " o, lo que es lo mismo, las deprecated features . Esta lista es útil para mantener nuestra aplicación actualizada , de tal forma que podamos seguir usando las nuevas funcionalidades de las sucesivas versiones SQL Server. Mantener en nuestro código alguna característica marcada como obsoleta o en desuso implicaría que no podríamos ejecutarlo en la versión de SQL que ya no la soportase. Pues bien, en dicha lista aparecen tanto las características que no serán soportadas en la próxima versión de SQL Server como las que estarán en desuso en futuras versiones. Esta segunda lista es muy amplia, pero si leemos detenidamente en ella nos encontraremos con, al menos, una característica que nos llamará la atención : "Not ending Transact-SQL statements with a semicolon." Es decir, Microsoft pretende que deje de ser opcional -como lo es hasta ahora- finaliz...

En algunas ocasiones podemos vernos con la necesidad de conocer qué tablas de nuestra base de datos están ocupando más espacio en disco. Por ejemplo, si disponemos de SQL Server Express , cuyas bases de datos están limitadas a 4GB o 10GB, según la versión que estemos usando -4, hasta 2005; 10, a partir de 2008-, aparte de usar las opciones de comprimir la base de datos, poner el log en el modo simple de recuperación o ajustar las políticas de crecimiento automático de nuestros ficheros, podemos necesitar averiguar qué tablas crecen más para tomar las decisiones oportunas.

Con SQL Server 2008 llegó IntelliSense para T-SQL. IntelliSense es una herramienta que nos ofrece el editor de SQL Server Management Studio para facilitarnos la escritura de código T-SQL. Básicamente, entre otras cosas, carga el catálogo de nuestra base de datos para facilitarnos la escritura de consultas.