Schemas

SQL Server desde la version 2005 nos ofrece como una de las nuevas características el uso de schemas, ¿para qué sirven, que son, realmente es importante calificar los nombres de los objetos con el esquema al que pertenecen?

Los esquemas son objetos que sirven como contenedores de otros objetos, para la gente que es de tecnología de .NET la analogía serian los NameSpaces. Los esquemas nos permiten agrupar objetos en ellos.

La sintaxis para crear un esquema es

Create Schema [NombreEsquema] AUTHORIZATION [NombreUsuario]

Tambien lo podemos crear mediante el asistente para lo cual abrimos el Managment Studio/Object Explorer, nos colocamos en el nodo de nuestra Base de Datos, despues en el nodo [Security] y dentro de el en el nodo [Schemas] podemos crearlo haciendo click con el botòn derecho en la opcion Nuevo esquema.


Vamos a crear nuestro esquema y continuaremos profundizando sobre su uso

Create Schema Audit;

Como se menciono antes los esquemas nos permiten contener objetos de Base de datos.
Crearemos un par de tablas que estaran dentro del esquema Audit.

Create Table Audit.Tbl_Eventos
(
ID Int Identity(1,1) Primary key
,Evento varchar(100)
);
GO
Create Table Audit.Tbl_Usuarios
(
ID Int Identity(1,1) Primary key
,Usuario varchar(100)
);

Veamos como funciona esto mendiante un select a nuestras tablas antes creadas
Lo que muchas veces hacemos al invocar el nombre de un objeto es apuntar directamente a el con algo como:

Select * from Tbl_Eventos;

Lo cual si lo ejecutan veran que les ha generado un error ¿Por qué? , la razon es porque desde SQL 2005 los nombres de objetos se califican mediante cuatro partes [DBServerName].[DBName].[Schema].[Table], en la version de SQL 2000 los nombres se calificaban de una manera un poco distinta y era mediante [DBServer].[DBName].[ObjectOwner].[Table]

Analizando lo anterior,lo que debemos entender es que SQL antes calificaba los nombres de objetos directamente asociandolos al propietario.Desde SQL 2005 los objetos no le pertenecen directamente a un usuario, a quien estan vinculados es a un esquema y el esquema tiene un dueño, esto nos habre posibilidades de las cosas que podemos hacer con los esquemas.
Nuestra instrucción Select debe quedar de la forma

Select * from Audit.Tbl_Eventos;

¿Por qué es bueno indicar el nombre del esquema? SQL al resolver una petición y no tener especificado el esquema al que pertenece el objeto invocado tiene que determinar si existe en el esquema que tiene por default el usuario firmado, parece poco, sin embargo todo es importante y al calificar nuestra tabla con el esquema nos aseguramos de indicarle a SQL en que esquema esta nuestra tabla.
Los esquemas además nos sirven muy bien para asegurar los accesos a nuestros objetos, imaginemos que tenemos cien tablas dentro del esquema Audit y que tenemos que dar acceso de solo lectura a todas ellas a un usuario nuevo, siempre que pensemos en resolver algo lo debemos hacer en términos de “con el menor esfuerzo”.
La instrucción que nos permite asignarle algún permiso
GRANT [Permiso] ON SCHEMA::[SchemaName] TO [NombreUsuario]

Ejemplo:
CREATE LOGIN MyLogin WITH PASSWORD='pa$w00rd'
GO
CREATE USER MyLogin FROM LOGIN MyLogin

GRANT SELECT ON SCHEMA::[Audit] TO [MyLogin]
¿Pero que sucede si un dia necesitamos cambiar de un esquema la ubicación de una tabla? Eso es relativamente sencillo.
Con la instrucciòn Alter Schema lo podemos hacer
Ejemplo
Create schema Audit2
--transferir objetos
Alter schema Audit2 Transfer Audit.Tbl_Eventos

Como podemos ver es realmente simple cambiar de esquema una table.
Por último me gustaría mencionar algo que se llaman Sinónimos en SQL y que nos pueden ahorrar un poco de trabajo al nombrar objetos.
Los sinónimos no son más que objetos que nos sirven para asignarle un alias a otro objeto, si este está en un esquema podemos ahorrarnos entonces tener que escribir el esquema y el nombre completo del objeto.
Ejemplo:
Create Synonym AD For Audit2.Tbl_Eventos
Select * from Ad

Con esto terminamos el post sobre esquemas, solo quiero volver a mencionar la importancia de pensar en términos del menor esfuerzo, ¿Qué significa, que implica? Lo que implica es que sepamos diversas soluciones a un problema, que sepamos o que busquemos cual es la mejor y eso con el pasar del tiempo nos dara oportunidad de tener más tiempo que debemos ocupar en aprender, aprender y seguir aprendiendo. Es redondo, cuando nos preocupamos y ocupamos por lo importante antes que lo urgente nos hace mejores profesionistas. Recuerdo con afecto a un jefe hace años , bastante severo en algunas cosas, pero con mucha experiencia y la verdad con mucha sabiduría.

Un día llamandome la antencion me dijo :Charly imaginate que vas en carretera, conduces tu auto, te urge llegar a tu destino es urgentísimo llegar, pero te das cuenta que la gasolina no te alcanzara, ¿Qué debes hacer? La reflexion es que lo urgente es llegar , pero lo importante es que tengas como hacerlo, se tendria uno que dar un tiempo para recargar gasolina.

Así mismo en nuestro trabajo tenemos lo urgente y lo importante, lo importante es que nuestro conocimiento sea más amplio en buscar la mejor forma de resolver un problema lo cual nos llevara a ser mejores profesionistas y a encajar mejor en nuestro empleo, a poder ayudar de una mejor forma a la empresa para la que trabajamos y eso se los aseguro se traducirá en bienestar para nosotros.
Esto no quiere decir que debemos ser obsesivos con la perfección en más de una ocasión yo he tenido que decidir que así como esta mi código debe quedarse aunque no sea la mejor forma, porque si no nunca terminaríamos un proyecto.

Les dejo mis mejores saludos, y espero les sea de utilidad este post.