Aprendiendo SQL Server

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 ejecutable

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 tabla compl

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