Aprendiendo SQL Server

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

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