El Transact SQL (T-SQL) es un lenguaje de programación utilizado en Microsoft SQL Server y otras bases de datos relacionales. Aquí se presentan algunas buenas prácticas que pueden ayudar a garantizar un código T-SQL eficiente, seguro y fácil de mantener:
- Utilizar comentarios: Es importante utilizar comentarios en el código T-SQL para explicar lo que se está haciendo. Esto facilita la comprensión del código a otros desarrolladores y a ti mismo si regresas al código en una fecha posterior.
- Evitar el uso de cursores: En la medida de lo posible, se deben evitar los cursores en T-SQL ya que su uso puede disminuir el rendimiento del código. En su lugar, se pueden utilizar consultas y operaciones de conjunto para obtener los mismos resultados.
- Utilizar nombres de objetos descriptivos: Los nombres de objetos como tablas, vistas y procedimientos almacenados deben ser descriptivos para que su función sea clara y fácil de entender. Los nombres cortos y crípticos pueden ser confusos y dificultar la comprensión del código.
- Usar índices adecuados: La optimización de consultas es un aspecto crítico del rendimiento de una base de datos. Es importante utilizar índices adecuados para acelerar las consultas y mejorar el rendimiento general de la base de datos.
- Validar la entrada del usuario: Cuando se aceptan entradas del usuario, se debe validar esa entrada para garantizar que cumpla con las expectativas del código y no represente un riesgo de seguridad.
- Utilizar transacciones adecuadas: Las transacciones se utilizan para garantizar que se completen todas las operaciones del código o ninguna. Es importante utilizar transacciones adecuadas para garantizar la integridad de los datos.
- Mantener el código limpio: Se debe mantener el código T-SQL limpio y ordenado. Esto facilita la lectura del código y su mantenimiento en el futuro.
En resumen, estas son algunas buenas prácticas para seguir al escribir código T-SQL. Estas prácticas pueden ayudar a garantizar un código eficiente, seguro y fácil de mantener.
EN SELECT
- No utilizar un SELECT *, y esto más que buena práctica debería ser regla
- No use la cláusula into nombre de tabla (“SELECT… INTO”). Esto bloqueará mientras se ejecuta la consulta las tablas del sistema. En su lugar cree primero las tablas y luego re-escribe la sentencia como INSERT INTO tabla_name SELECT.
- Si usa el operador UNION y existe la seguridad de que ambos select NO tienen registros duplicados, entonces es mejor usar UNION ALL, para evitar que implícitamente se haga uso del operador DISTINCT el cual puede requerir que se almacenen todos los datos de salida en una tabla temporal para que luego se reordenen y se filtren los datos duplicados, lo cual aumenta considerablemente el costo de la consulta.
- Es recomendable usar joins a un subquery.
- lo primero que se efectúa en una consulta es el JOIN por tanto si podemos incluir allí una condición que tenemos en el WHERE mejor, ya que no tendrá que hacer el JOIN y luego aplicar otro filtro.
- En lo posible usar lo menos posible un ORDER BY dentro de la consulta y dejarlo del lado del cliente o de la aplicación, ésta es una de las operaciones que más consume recursos en una consulta.
- Dividir las consultas ayudara a que la mayoría de los datos carguen en memoria y no en disco lo cual es mas lento, por esto es mejor hacer consultas que no traigan muchos registros (100,000 por ejemplo) y operar con ellos.
- Promover el uso de EXISTS y NOT EXISTS, en lugar de IN y NOT IN.
- Especificar el alias de la tabla delante de cada campo definido en el select, esto le ahorra tiempo al motor de tener que buscar a que tabla pertenece el campo especificado.
- 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
Procedimientos Almacenados
- Los procedimientos almacenados de las aplicaciones no deben hacer llamadas a procedimientos almacenados del sistema. Por ejemplo: sp_updatestats.
- 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 o su dueño) En cada base de datos que tenga dbo como dueño, si el dueño no fue proporcionado. No escribir sentencias con los valores en duro, en su lugar use variables que sean del mismo tipo que la columna de la tabla. Esto permite eliminar las conversiones implícitas y mejora le legibilidad del código. - Se recomienda que un procedimiento no sobrepase las 400 líneas de código (sin contemplar los comentarios). En caso que tengas un procedimiento demasiado grande es más adecuado particionarlo. Tener en cuenta que las tablas temporales y transacciones se mantienen en procedimientos dependientes.
- Configurar set nocount on al inicio del procedimiento almacenado para anular el mensaje de filas afectadas dado que generan procesamiento innecesario.
- No usar GOTO… en remplazo usar Try Catch
- 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.
WHERE
- Las columnas filtro TIENEN QUE SER del mismo tipo de la columna que existe en la tabla (para evitar conversiones al momento de ejecución)
- No usar funciones sobre columnas que están en el Where dado que SQL no tiene índices basados en funciones por lo que tendría que recorrer toda la tabla.
- No usar concatenaciones de cadenas
- Si se usa LIKE en la cláusula WHERE, se debe evitar el uso del operador “%” al principio de la cadena a buscar dado que originaria que se tienen que leer todos los datos de la tabla para poder responder dicha consulta, adicionalmente es recomendable que existan (como mínimo) 3 caracteres antes del operador “%”.
- Index Scan -> %cadena
- Index Seek cadena%
- Si una consulta tiene uno o más operadores OR, considera reescribir la consulta en varias consultas que se unen usando el operador UNION ALL.
Déjame un comentario si te fue útil el post 👇
