SQL Server 2008 R2 CTP November

Desde ayer está disponible la nueva CTP de noviembre de SQL Server 2008 R2, para suscriptores de MSDN y TechNet.

No dudéis en descargarla e ir conociendo de primera mano las interesantes novedades que aporta :)

No más "SELECT *..." en mis tablas

Creo que a estas alturas todo desarrolladoR ha oído y leído que es una mala práctica utilizar la sintaxis SQL SELECT * FROM. Por un lado nos encontramos con que el gestor de bases de datos debe obtener de los metadatos cuáles son las columnas que debe devolver, que aunque no sea una gran penalización, también afecta al rendimiento. Por otro lado nos encontramos con que la adición de una nueva columna a una tabla puede suponer que dejen de funcionar muchas consultas e informes que no se ven afectados por dicho cambio, al recibir la aplicación más columnas de las esperadas.

Bien, pues todos admitimos que no es una buena práctica, pero la seguimos llevando a cabo. No paro de encontrar servidores donde se siguen ejecutando una gran cantidad de las instrucciones que usan el asterisco " * ". Unas veces por pereza, otras por hábito, otras por ... El caso es que ahí está esa mala práctica, tan admitida como utilizada.

Pues bien, es hora de ponernos firmes y evitar este uso, si de verdad estáis decididos a hacerlo, aquí os dejo un script que impide el uso de la sintaxis SQL del SELECT * FROM. Esto es posible gracias al uso de:

DENY SELECT ON OBJECT:: TuEsquema.TuTabla(DummyColumn) TO Usuario;

Tened en cuenta que restringe también el uso del count(*), pero eso tiene solución fácil podéis utilizar count(Columna), pero es importante que conozcáis los matices de una y otra variante y el resultado diferente que se puede obtener en caso de haber nulos, cosa que podéis solucionar utilizando una columna que sea primary key, y que por tanto no admitirá nulos :)

Os recomiendo que leáis con detalle el artículo Preventing usage of "SELECT * ...", y sobre todo que lo pongáis en práctica.

Accede a las tablas mediante procedimientos almacenados, nunca directamente

Es una práctica muy habitual que muchos usuarios tengan acceso a las tablas. En muchas ocasiones simplemente necesitan utilizar una aplicación, con la que deben gestionar y mantener datos. Otras veces son los propios desarrolladores que lanzan instrucciones INSERT, UPDATE o DELETE sobre ellas, asumiendo un alto riesgo sobre la integridad de los datos.

En muchos sitios hemos leído que es una buena práctica de seguridad que no se tenga acceso directo a las tablas y que sólo se de acceso a vistas y procedimientos almacenados. Mi recomendación va más a allá, y es dar sólo acceso a procedimiento almacenados (cuando sea posible).

El problema o las razones que me suelen argumentar es el trabajo que esto supone, pero no es así:

- La creación de los procedimientos almacenados para Insert, Update y Delete, se puede automatizar con los muchos generadores que hay, o haciendo el nuestro propio.

- Luego hay que gestionar la seguridad, y es una lata tener que ir dando permisos para que pueda ejecutar cada usuario todos los procedimientos almacenados de la aplicación. Por ejemplo si tenemos 50 tablas, habrá como mínimo 200 procedimientos almacenados, contando que por cada tabla haya sólo una Insert, una Update, una Delete y una Select, cosa que no es cierta, y este número sería mayor.

Además deberíamos tener ciertas reglas de negocio en los procedimientos almacenados, esto complica un poco más su creación, pero si no lo hacemos, tendremos un gran riesgo en cualquier actualización manual que tengamos que hacer sobre las tablas.

Bueno, ¿y por qué os cuento todo esto? pues porque una de las dos tareas que aparentemente son tediosas, la de dar permisos a cada usuario para que pueda ejecutar todos los procedimientos almacenados, es muy simple, podéis utilizar el procedimiento almacenado spGrantExectoAllStoredProcs, que podéis encontrar en MS SQL Tips (un excelente sitio, que os recomiendo seguir).

Espero que esto ayude a convenceros de poner en práctica las buenas prácticas comentadas anteriormente :-)