Aprendiendo SQL Server

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 .