mty.Coders

Mejores Prácticas: SQL Server

Febrero 19th, 2009

Siempre es bueno llevar un conocimiento básico de los estándares y mejores prácticas en desarrollo y bases de datos. A continuación les proporciono con una lista de “best practices” para SQL Server (Que aplican también para muchos otros DBMS):

1. No usar Select *. Siempre que se utiliza Select * todas las columnas en la tabla o unión se incluyen en el conjunto de resultados, así que el incluir todas las columnas aunque no sean necesarias provoca un exceso de entradas/salidas en el servidor y un consumo innecesario del ancho de banda de la red.
2. Siempre mandar llamar procedimientos almacenados. No hay que enviar declaraciones Select, Insert, Delete o Update a la base de datos; en vez de eso, siempre hay que llamar procedimientos almacenados pasándole los parámetros correspondientes. El motivo de esta mejor práctica es el siguiente: cuando SQL Server recibe una consulta, como una declaración Select, lo primero que hace es compilarla, crear un plan de ejecución, y finalmente ejecutarlo; todos estos pasos consumen tiempo. Cuando se invoca un procedimiento almacenado, este procedimiento almacenado puede ser compilado si es la primera vez que es llamado, o si cambian las estadísticas que le afecten, pero en caso contrario no es compilado y es almacenado en el caché; el plan de ejecución también es almacenado en el caché. El llamar un procedimiento almacenado ahorra tiempo de ejecución y recursos, así que es una mejor práctica que no debe ser ignorada.
3. No grabar los procedimientos almacenados con un nombre con prefijo “sp_”. Cuando el nombre de un procedimiento almacenado comienza con “sp_”, SQL Server lo busca en el siguiente orden:
   En la base de datos maestra En la base de datos determinada por los calificativos proporcionados (nombre de la base de datos u su dueño) En cada base de datos que tenga dbo como dueño, si el dueño no fue proporcionado
4. Usar la cláusula Join con estándar ANSI. Para unir tablas es mejor usar la cláusula Join que hacer una unión por medio de la cláusula Where. A pesar de que a partir de SQL Server 7.0 las uniones de tablas usando Where pueden ser traducidas por el plan de ejecución a uniones explícitas, el hecho es que el compilador es quien hace esa conversión, lo cual le toma tiempo y recursos.
5. Evitar el uso de cursores en los procedimientos almacenados. Los cursores en SQL Server son recursos muy caros, lo cual hace mas lento el desempeño de las consultas. Se debe evitar en lo posible el uso de cursores.
6. Utilizar SET NOCOUNT ON. Al crear procedimientos almacenados, se puede mejorar el desempeño de ADO eliminando los valores innecesarios de la cantidad de renglones afectados, del conjunto de datos de salida, con solo agregar la instrucción SET NOCOUNT ON en el procedimiento almacenado.
7. Minimizar el uso de tablas temporales. Aunque las tablas temporales generalmente son una estructura en memoria, lo cual puede parecer que es una solución de acceso rápido, eso no significa que este enfoque mejore el desempeño; de hecho, esto empeorara el desempeño. El motivo de esto es que la estructura de una tabla temporal no la conoce de antemano el optimizador de consultas, por lo tanto el optimizador necesita recompilar el plan de ejecución una vez que la conoce; esto es, después de que la tabla temporal es creada. Muchas veces, el tiempo que le toma recompilar el procedimiento es mayor que el tiempo de la ejecución misma.
8. Usar tablas derivadas siempre que sea posible. Las tablas derivadas tienen un mejor desempeño. Considerando la siguiente consulta para encontrar el segundo salario mas alto de la tabla de Empleados:
   SELECT MIN(Salary) FROM Employees WHERE EmpID IN ( SELECT TOP 2 EmpID FROM Employees ORDER BY Salary DESC ) La misma consulta puede ser re-escrita usando una tabla derivada, como se muestra a continuación, y será el doble de rápida que la consulta anterior: SELECT MIN(Salary) FROM ( SELECT TOP 2 Salary FROM Employees ORDER BY Salary DESC ) AS A
9. Evitar el uso de caracteres comodín al inicio de una palabra al usar el identificador LIKE. Se debe intentar evitar el uso de caracteres comodín al inicio de una palabra al hacer una búsqueda usando el identificador LIKE, ya que eso ocasiona un rastreo en el índice (index scan), lo cual se contrapone con el objetivo de usar índices. El primero de los siguientes códigos genera un rastreo en el índice, mientras que el segundo genera una búsqueda en el índice (index seek):
   SELECT LocationID FROM Locations WHERE Specialities LIKE „%pples? SELECT LocationID FROM Locations WHERE Specialities LIKE „A%s? También se deben evitar las búsquedas utilizando operadores de no igualdad (<> y NOT) ya que éstos resultan en rastreos de índices y tablas.
10. Evitar el uso de sugerencias (hints). Las sugerencias sobrepasan la optimización de consultas y pueden prevenir que el optimizador de consultas escoja el plan de ejecución más rápido. Debido a cambios en el optimizador, las sugerencias que mejoraban el desempeño en versiones previas de SQL Server pueden no tener efecto o incluso empeorar el desempeño en SQL Server 7.0 y 2000. Además de esto, las sugerencias a las uniones pueden causar degradación del desempeño.
    Las sugerencias a las uniones previenen que una consulta sea elegible para la auto-parametrización y subsecuente almacenamiento en caché del plan de ejecución. Cuando se usa una sugerencia a la unión, implica que se quiere forzar el orden de unión para todas las tablas en la consulta, aun y si las otras uniones no usan explícitamente una sugerencia. Si la consulta que se está analizando contiene cualquier sugerencia, debe removerse y re-evaluar su desempeño.
11. Tratar de no usar tipos de datos TEXT o NTEXT para almacenar datos textuales grandes. El tipo de datos TEXT tiene ciertos problemas inherentes a él. Por ejemplo, no se puede grabar o actualizar datos de texto usando las instrucciones INSERT o UPDATE. En vez de eso, es necesario usar declaraciones especiales como READTEXT, WRITETEXT y UPDATETEXT. También existen muchos errores asociados con la replicación de tablas que contienen columnas de tipo TEXT. Por eso, si no se necesita almacenar más de 8 KB de texto, es preferible usar los tipos de datos CHAR (8000) o VARCHAR (8000).
12. De ser posible, no almacenar archivos binarios o de imagen (Binary Large Objects o BLOBs) en la base de datos. En vez de eso, almacenar la ruta al archivo binario o de imagen en la base de datos y usarla como apuntador al archivo actual almacenado en otra parte del servidor. Es mejor recuperar y manipular estos grandes archivos binarios fuera de la base de datos, y después de todo una base de datos no esta hecha para almacenar archivos.
13. Usar el tipo de datos CHAR para una columna solamente cuando no pueda contener valores nulos. Si una columna CHAR puede contener valores nulos, es tratada como una columna de ancho fijo en SQL Server 7.0+. Así que un CHAR (100) cuando sea nulo ocupara 100 bytes, resultando en un desperdicio de espacio. Para esta situación es mejor usar VARCHAR (100). Ciertamente las columnas de ancho variable tienen un poco más de overhead de procesamiento en comparación con las columnas de ancho fijo. Se debe escoger con cuidado entre CHAR y VARCHAR dependiendo del ancho de los datos que se van a almacenar.

Categorías: DBMS, Destacados, Estándares, Programación

Etiquetas: almacenados, best, manera, mejor, mejores, ms, practicas, practices, procedimientos, procedures, select, server, sql, sql server, stored Dejar un comentario