Mejores Prcticas: SQL Server | mty.

Coders

Pgina 1 de 4

Inicio

Mejores Prcticas: SQL Server

Categora(s): DBMS, Destacados, Estndares, Programacin Autor: lemiffe Siempre es bueno llevar un conocimiento bsico de los estndares y mejores prcticas en desarrollo y bases de datos. A continuacin les proporciono con una lista de best practices para SQL Server (Que aplican tambin para muchos otros DBMS): 1. No usar Select *. Siempre que se utiliza Select * todas las columnas en la tabla o unin 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. 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 pasndole los parmetros correspondientes. El motivo de esta mejor prctica es el siguiente: cuando SQL Server recibe una consulta, como una declaracin Select, lo primero que hace es compilarla, crear un plan de ejecucin, 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 estadsticas que le afecten, pero en caso contrario no es compilado y es almacenado en el cach; el plan de ejecucin tambin es almacenado en el cach. El llamar un procedimiento almacenado ahorra tiempo de ejecucin y recursos, as que es una mejor prctica que no debe ser ignorada. 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 dueo) En cada base de datos que tenga dbo como dueo, si el dueo no fue proporcionado Usar la clusula Join con estndar ANSI. Para unir tablas es mejor usar la clusula Join que hacer una unin por medio de la clusula 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 ejecucin a uniones explcitas, el hecho es que el compilador es quien hace esa conversin, lo cual le toma tiempo y recursos. Evitar el uso de cursores en los procedimientos almacenados. Los cursores en SQL Server son recursos muy caros, lo cual hace mas lento el desempeo de las consultas. Se debe evitar en lo posible el uso de cursores. Utilizar SET NOCOUNT ON. Al crear procedimientos almacenados, se puede mejorar el desempeo de ADO eliminando los valores innecesarios de la cantidad de renglones afectados, del conjunto de datos de salida, con solo agregar la instruccin SET NOCOUNT ON en el procedimiento almacenado. Minimizar el uso de tablas temporales. Aunque las tablas temporales generalmente son una estructura en memoria, lo cual puede parecer que es una solucin de acceso rpido, eso no significa que este enfoque mejore el desempeo; de hecho, esto empeorara el desempeo. 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 ejecucin una vez que la conoce; esto es, despus de que la tabla temporal es creada. Muchas veces, el tiempo que le toma recompilar el procedimiento es mayor que el tiempo de la ejecucin misma. Usar tablas derivadas siempre que sea posible. Las tablas derivadas tienen un mejor desempeo. 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 continuacin, y ser el doble de rpida que la consulta anterior: SELECT MIN(Salary) FROM ( SELECT TOP 2 Salary FROM Employees ORDER BY Salary DESC ) AS A Evitar el uso de caracteres comodn al inicio de una palabra al usar el identificador LIKE. Se debe intentar evitar el uso de caracteres comodn al inicio de una palabra al hacer una bsqueda 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 cdigos genera un rastreo en el ndice, mientras que el segundo genera una bsqueda en el ndice (index seek): SELECT LocationID FROM Locations WHERE Specialities LIKE %pples? SELECT LocationID FROM Locations WHERE Specialities LIKE A%s? Tambin se deben evitar las bsquedas utilizando operadores de no igualdad (<> y NOT) ya que stos resultan en rastreos de ndices y tablas. Evitar el uso de sugerencias (hints). Las sugerencias sobrepasan la optimizacin de consultas y pueden prevenir que el optimizador de consultas escoja el plan de ejecucin ms rpido. Debido a cambios en el optimizador, las sugerencias que mejoraban el desempeo en versiones previas de SQL Server pueden no tener efecto o incluso empeorar el desempeo en SQL Server 7.0 y 2000. Adems de esto, las sugerencias a las uniones pueden causar degradacin del desempeo. Las sugerencias a las uniones previenen que una consulta sea elegible para la auto-parametrizacin y subsecuente almacenamiento en cach del plan de ejecucin. Cuando se usa una sugerencia a la unin, implica que se quiere forzar el orden de unin para todas las tablas en la consulta, aun y si las otras uniones no usan explcitamente una sugerencia. Si la consulta que se est analizando contiene cualquier sugerencia, debe removerse y re-evaluar su desempeo. 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. Tambin existen muchos errores asociados con la replicacin de tablas que contienen columnas de tipo TEXT. Por eso, si no se

http://mtycoders.com/?p=317

27/11/2009

Mejores Prcticas: SQL Server | mty.Coders

Pgina 2 de 4

necesita almacenar ms de 8 KB de texto, es preferible usar los tipos de datos CHAR (8000) o VARCHAR (8000). 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 despus de todo una base de datos no esta hecha para almacenar archivos. 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 situacin es mejor usar VARCHAR (100). Ciertamente las columnas de ancho variable tienen un poco ms de overhead de procesamiento en comparacin 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. Tags: almacenados, best, manera, mejor, mejores, ms, practicas, practices, procedimientos, procedures, select, server, sql, sql server, stored Febrero 19th, 2009 5 comentarios Deja tu comentario roberto Says:
Marzo 31st, 2009 at 9:40 am

Me interesa mucho el punto 12. De ser posible, no almacenar archivos binarios o de imagen (Binary Large Objects o BLOBs) en la base de datos. Tienes algunos links donde pueda sacar ms informacin y as sustentar mi desicin?? lemiffe Says:
Marzo 31st, 2009 at 10:47 am

He buscado sin embargo no he obtenido una fuente de informacin confiable acerca de esa declaracin. No hay Una razn por la que sea equivocado usarlo. La razn principal es espacio en mi opinin. Si estas manejando una base de datos en un portal web, o un blog, o una wiki, almacenar las imgenes en la base de datos harn que sea impractico descargar un respaldo de la base de datos ya que tomar mucho tiempo, especialmente cuando se ha estado usando constantemente durante un ao o ms. Por eso mismo wordpress, wikimedia y otras aplicaciones que permiten subir texto e imagenes y usan una base de datos NO suben las imagenes como binary large objects sino que los suben fisicamente al servidor como archivos y hacen una referencia hacia la ubicacin del archivo. Cuando no usarlos? Cuando deseas ahorrar espacio. Cuando usarlos? Cuando requieres embebir esas imagenes o contenido multimedia en aplicaciones donde no te permite cargar contenido mas que por medio binario, y no cuentas con un lenguaje para cargarlo y mostrarlo, como en algunas aplicaciones COM de la decada anterior. Creo que en Crystal Reports en versiones anteriores para mostrar una imagen dinmica (que pudiera cambiar dependiendo de los datos que se le pasaban al llamarsele) se requera pasar la imagen como binario. alexis Says:
Septiembre 18th, 2009 at 2:23 pm

en cuanto a las bases de datos en sql, cual es la cantidad maxima de caracteres para el nombre y la misma pregunta para el caso de las tablas y campos? si sabes te agradeceria la informacion. lemiffe Says:
Septiembre 20th, 2009 at 9:32 pm

Que tal Alexis, La verdad no he investigado sobre la longitud de caracteres para el nombre de la base de datos, y de las tablas y campos, estoy suponiendo que es 256. Sin embargo no tengo ese dato con exactitud, puesto a que nunca he tenido que hacer un nombre de base de datos o de una tabla con tal longitud que exceda el lmite. No has intentado hacer una prueba directamente en la base de datos? Marco Says:
Septiembre 25th, 2009 at 5:19 pm

Hola, respecto al punto 4. Me gustara saber si hay alguna otra diferencia en cuanto a desempeo en el uso de la sintaxis Ansi, adems del tiempo que usa el compilador en traducir a uniones explcitas. Gracias. Deja tu comentario
Name (required) Mail (will not be published) (required) Website

http://mtycoders.com/?p=317

27/11/2009

Mejores Prcticas: SQL Server | mty.Coders

Pgina 3 de 4

Submit Comment

mty.Coders
mty.Coders Eventos Guas m.C Informacin Registro Servicios Tutorials Comunidad de Desarrolladores de Monterrey

Explora MtyC

Blogs
[ESP] Hctor Prez .NET Weblog [Esp] Mujeres TIC [Esp] My Content Pipeline [Ing] Engadget [Ing] Gizmodo [Ing] Hanselman [Ing] LeMiffe: Life & IT [Ing] TechCrunch [Ing] Wired [Ing] Wundas World

Ligas

Citiria.com Grupo Usuario Linux mty.Coders Forum MySmallBook ReadWriteWeb Siguenos: Twitter Solvantec Software TechDosh

MtyC en Twitter
Ya no usen Split() en #PHP por favor... Preg_Split tiene que tomar forma. (Casi se me olvidaba). 2 weeks ago Ubuntu 9.10, pura sabrosura! 2 weeks ago RT @hashjs: Tell me, why is everyone now using #js as a base language? Something awesome in it's design I missed?(via @almadcz) <- It rocks 2 weeks ago Leer Mas Tweets...

Lo Mejor en MtyC
ASP.NET: DataBinding en-lnea y Operadores Ternarios (3338) Estndares de Nomenclatura en Programacin y Bases de Datos (2124) Mejores Prcticas: SQL Server (1758) Comandos equivalentes del MS-DOS a Gnu/Linux (1727) Modelo de Desarrollo de Software basado en Iteraciones (Versin 0.1) (1496)

Algunos Trminos
.net Apple asp.net c# chrome desarrolladores desarrollo Estndares explorer firefox foro

Google ie8 Internet internet explorer

http://mtycoders.com/?p=317

27/11/2009

Mejores Prcticas: SQL Server | mty.Coders

Pgina 4 de 4

iPhone iteraciones javascript linux Microsoft minefield modelo monterrey

mty.coders Navegadores opera php presentacion

programacion programadores rpido safari Seguridad server software sql TI Ubuntu vb vb.net vb6 vb6.0 web web2.0 Windows Login
Username: Password: Remember me
Login

Lost your password? mty.Coders funciona gracias a WordPress Template by Bright Cherry, modified by Solvantec. Image (Flickr) CC.

http://mtycoders.com/?p=317

27/11/2009