Sql tips 04_best_practices

GPI.- Confidencial

Tel: (506) 297 8132 – 244-5849 | De la Basílica de Santo Domingo, Heredia; 200 mts norte y 900 mts este. Apto 103-1100, Costa Rica

En el presente artículo presentaremos una serie de guías que se definen como mejores

prácticas para aplicaciones que hacen uso de base de datos. Obviamente los siguientes puntos

están basados principalmente en el enfoque de lo que es mejor para la base de datos, sin dejar

de lado aspectos importantes que como desarrolladores se deben de tomar en cuenta.

En muchas páginas en Internet, libros, blogs, se pueden concontrar muchas guías de mejores

prácticas, algunas de ellas son repetitivas entre una y otra página. Recientemente se publicó en

la convención de Sql Server Connections una guía, se puede puede decir que “Definitiva” con

mejores prácticas para DBA’s, para Desarrolladores, para Tunning, en fin para muchas cosas.

En las siguientes páginas les transcribo las mejores prácticas para Application Design and

Coding escritas por Brad M. McGehee quien ha sido MVP en Sql Server por mas de 10 años y ha

escrito mas de 10 libros sobre Sql Server. Las explicaciones a cada una de las mejores prácticas

son dadas por mi persona (Espero que me haya explicado bien, sino me avisan a ver como

hacemos ☺), y algunas mejores prácticas también las he incluído yo de acuerdo a situaciones

experimentadas en algunos de nuestros clientes.

Diseño de Base de Datos

1. Un mal diseño lógico lleva consigo un mal diseño físico de la base de datos y generalmente

resulta en un pésimo rendimiento en la base de datos, por tanto es necesario que se tome el

tiempo necesario para crear el diseño de una base de datos, esto implica esfuerzo y

principalmente tiempo para crear toda la estructura necesaria, esto va desde la cantidad de

tablas, hasta los tipos de datos que vamos a utilizar. Por lo general cuando pensamos en el

diseño de la base de datos nunca nos percatamos de la necesidad de definir el modelo físico y

no se imaginan ustedes la importancia que tiene el mezclar ambos diseños de una mejor forma.

Ambos están estrictamente relacionados.

2. Normalice las tablas, esto asegurará un buen rendimiento. Les comento que lo ideal es no tener

más de 20 columnas en una tabla, si se sobrepasa es porque no estaría normalizando

correctamente mis tablas.

3. Utilice la integridad referencial de Sql Server.

4. Al hacer uso de llaves primarias su comportamiento por defecto es el de crear dichas llaves

como índices Clustered, y es factible que nosotros no queramos que esto sea de esta manera,

sino mas bien nuestro deseo es el de tener otra columna como índice Clustered. En este caso les

recomiendo crear las llaves primarias por medio de código como por ejemplo de esta forma Create Table Empleados (

Id_Emp smallint identity Primary Key Nonclustered,

Ced_Emp varchar (25) not null,

Nom_Emp varchar (35) not null,

Ape1_Emp varchar (35) not null,

Ape2_Emp varchar (35) not null);

GO

CREATE CLUSTERED INDEX IDX_CL_Cedula ON Empleados (Ced_Emp);

GPI.- Confidencial


Otra de las formas que puede utilizar es mediante el Management Studio o Enterprise Manager

para Sql Server 2000 y cuando definan la llave primaria cambien su valor por defecto de

Clustered a Nunclustered. Esto es importante pues se dan casos en que finalmente deseo

realizar un ordenamiento o busqueda principal por fecha y sería de mucha utilidad tener la

fecha definida como un índice clustered. Por otro lado si lo que desean es crear llaves primarias

para no repetir campos, les recomiendo mejor utilizar UNIQUE INDEX por la cantidad de

columnas que no desean repetir antes de crear una llave primaria compuesta CLUSTERED. Por

AMC.

5. Cuando especifique los tipos de datos de las columnas trate de que los mismos sean lo mas

pequeños porsibles esto hace que Sql Server deba de almacenar menos cantidad de datos y el

tiempo de respuesta se reduce significativamente. Luego vamos a ahondar un poco en los tipos

de datos.

6. Evite el utilizar transacciones que involucren utilizar comandos TSQL y MDX (OLAP) en un mismo

servidor, esto significa nunca tener los dos motores de base de datos JUNTOS.

7. No se vuelvan locos definiendo índices en todas las colunmas habidas y por haber, recuerden

que Sql va a crear cuantos malos índices le digamos, así que seamos cautos en este tema,

veamos el siguiente ejemplo

CREATE INDEX IDX_NCL_APELLIDO ON Empleados(Ape1_Emp);

CREATE INDEX IDX_NCL_APELLIDO2 ON Empleados(Ape1_Emp);

CREATE INDEX IDX_NCL_APELLIDO3 ON Empleados(Ape1_Emp);

Esto nos estaría creando tres índices con nombre distinto sobre la misma columna, y Sql lo

permite, no se engañen, cualquier motor de base de datos funciona igual. ☺ Por AMC

8. Crear Filegroups adicionales para que los objetos de usuario residan en estos filegroups.

Principalmente si nuestra base de datos va a ser grande, pensemos en la distribución de objetos

según su importancia. Dejar el Primary Filegroup únicamente para los objetos de sistema.

9. Crear FILES adicionales para la base de datos TEMPDB, esto ayuda a mejorar el procesamiento,

los archivos deben de ser del mismo tamaño. No se deben de crear tantos archivos como CPU’s

tenga el servidor, esto por el contrario puede general problemas de IO en nuestro motor de

base de datos, pues los archivos crecen al mismo tiempo y si son muchos esto genera colas en el

sistema de discos.

10. Pidan ayuda, no todos somos expertos en temas de base de datos y hay compañeros que

pueden tener una mejor formación. Como diría alguien por ahí, “Mas vale un minuto de

vergüenza que toda una vida de ignorancia” Por AMC

Queries y Stored Procedures

1. Mantener el código en un “Source Control”, aplica solo para Sql Server 2005 que si mantiene su

propio “Source Control”

2. Mantener las transacciones lo más pequeñas posibles, cuando iniciamos un Begin Transacction

debemos hacer Commit lo antes posible, pues lo que hagamos dentro de ellos implica bloqueos

serios a nivel de Sql Server.

GPI.- Confidencial


3. No utilice HINTS al menos que sepan para que los están utilizando, los HINTS se pueden crear

por ejemplo para indicarle a una consulta que utilice X índice, o bien que no se realicen

bloqueos a nivel de tablas, pero el realizar este tipo de tareas implica que el motor no utilice los

recursos de una mejor manera o bien que realice mas lecturas de las debidas. Por AMC

4. Encapsular las transacciones en Stored Procedures, incluyendo los Begin Tran y Commit Tran. 5. Utilice el menos restrictivo nivel de aislamiento en lugar de siempre Utilizar el default Read

Commited. Ojo esto aplica para Sql Server 2005 que introduce el Snapshot Isolation Level, para

2000 no les recomendaría el estarlo cambiando. Por AMC 6. Las aplicaciones deberían de enviar sus comandos TSQL por medio de Stored Procedures, no en

la forma de una sentencia simple, pues esto reduce la cantidad de paquetes que viajan por la

red, además que los planes de ejecución de un SP pueden ser reutilizados pues se mantienen en

Cache. El Stored Procedure permite reutilización de código, además que e trabajar con SP

permite que los cambios se hagan a nivel de base de datos lo cual no afectaría la aplicación,

reduciendo el mantenimiento y cambios a la misma. Además los SP brindan mejor seguridad

para los datos 7. SET NOCOUNT ON al inicio de cada SP, se debe de indicar en todos y cada uno de los SP que se

creen. 8. Revise sus SP, verifique si al realizar algún cambio quedó código que ya no es utilizado como

variables, parámetros, entre otros. 9. Los SP siempre deben de pertenecer a un mismo dueño o esquema para mejoras en

rendimiento y siempre deben de hacer referencia de la forma owner.sp_name o bien

schema.sp_name 10. Nunca llamen a sus Stored Procedures con el prefijo SP, pues su resultado inicial es el de ir a

buscar el SP a la base de datos MASTER, luego pasa a buscar a sus bases de datos en sus SP de

sistema y por último pasaría a la base de datos en donde reside el SP. Perdiendo un tiempo

valioso. Por AMC 11. Mantener la lógica de negocio en la capa aplicativa, Sql Server no está diseñado para realizar

cálculos (Como los de una planilla o cálculos de comisiones para comercios), utilicen la capa de

datos para lo que es, para almacenar datos y manipularlos. 12. Cuando se utilizan variables en los SP, no utilicen las mismas que vienen del SP para sus

inserciones o cálculos, creen variables locales en el SP y asignen sus parámetros a las variables

locales que recién han creado.

GPI.- Confidencial


TSQL

1. Siéntanse libres de poner comentarios, más bien esos gestos se agradecen. Los comentarios no

afectan los SP, eso si, la idea es que siempre el SP quede legible.

2. De ser posible evítense los cursores, utilizan muchos recursos de Sql Server.

3. Cuando se utilicen los UNIONS tengan en consideración que es equivalente a realizar un Distinct,

o sea en pocas palabras es malo… Además el Union utiliza planes de ejecución por cada query

en lugar de utilizar un solo plan de ejecución. Así que tengan cuidado con el uso de los UNIONS. Por AMC

4. Utilice con cuidado el DISTINCT, muchos de nosotros tenemos la costumbre de utilizarlo en

cuanta sentencia requerimos y esto implica consumo innecesario en recursos de la base de

datos. Utilícese solo cuando se requiera.

5. No utilice Select * en sus consultas.

6. Siempre utilice WHERES en las sentencias, esto implica retornar menos cantidad de registros por

cada filtro que se realice.

7. Cuando se deba de escoger entre un IN y un Between, utilice el Between, se obtienen mejores

resultados en rendimiento.

8. Utilice la cláusula TOP en las consultas para restringir la cantidad de filas que se devuelven en un

SELECT

9. No utilice lógica negativa, siempre pregunten por lo que es positivo.

10. Traten de evitar el LIKE.

11. Utilicen siempre los planes de mantenimiento para validar sus consultas, esto permite un mejor

control de lo que realizamos y nos ayuda a realizar desarrollos de calidad.

Technology

Sql tips 04_best_practices