Manual Buenas Prácticas Codificación SQL Server
MANUAL DE REFERENCIAManual Buenas Prácticas SQL Server Página 2 de 8
Fecha Versión Descripción Autor
1.0 Creación del Manual Ricardo Larriega
Manual Buenas Prácticas SQL Server Página 3 de 8
Contenido
Historia de Revisión ... 2 Objetivo ... 4 Estándares de Nomenclatura ... 4 Documentación ... 4 Lectura ... 4 Escritura ... 5 Joins ... 5 Where ... 6 Generales ... 7 Transaccionalidad ... 8Manual Buenas Prácticas SQL Server Página 4 de 8 Incentivar a analistas y desarrolladores aplicar un enfoque orientado a la optimización de los aplicativos de Interseguro a través del uso de estándares y buenas prácticas
Estándares de Nomenclatura
1. Los nombres de las tablas deben estar en singular, no se debe utilizar espacios en blanco en el nombre y deben estar relacionados con la data que van a almacenar.
2. Los nombres de los triggers deben seguir el estándar
ut_<nombre>
3. Los nombres de los vistas deben seguir el estándar
vw_<nombre>
4. Los nombres de los procedimientos almacenados (stored procedures) deben seguir el estándar
usp_<nombre>
, no usar sp_ que es un error5. Los índices se nombran considerando la tabla a la que están relacionados y el propósito del índice.
-Las claves primarias utilizan el texto “PK” como sufijo o prefijo, según se considere conveniente
-Las claves foráneas utilizan el texto “FK” como sufijo o prefijo, según se considere conveniente
-Los índices agrupados (clustered) utilizan el sufijo o prefijo “IDX”, según se considere conveniente
Documentación
1. Anexar comentarios al inicio de los stored procedures del fin del stored procedure /************************************************************** Objetivo: <Descripción>
Creado por: Fecha creación: Modificado por:
Última modificación: <Descripción> Fecha modificación:
*************************************************************/
Lectura
1. Evita usar SELECT *. Siempre lee solo las columnas que necesitas. Con esto evitas llevar mucha data que no se necesita al cliente, entonces se descongestiona la red y el cliente siente que es más rápido.
2. Para consultas de listas de registros, usa el operador TOP n. Con esto evitamos llevar muchos registros al cliente. También se descongestiona la red y el cliente siente que es más rápido. 3. En lugar de SET ROWCOUNT n, usa TOP n.
4. Si usas el operador UNION y estás seguro que ambos queries NO tienen registros duplicados, entonces mejor usa UNION ALL, para evitar que implícitamente se haga uso del operador DISTINCT
Manual Buenas Prácticas SQL Server Página 5 de 8 5. Evita usar SELECT … INTO table_name. Esto bloquerá tablas del sistema. En lugar de esto, crea
primero las tablas y luego re-escribe la sentencia como INSERT INTO table_name SELECT ... 6. Si vas a leer data de una sola tabla, evita hacerlo usando vistas que usan otras tablas 7. Evitar el uso de sentencias select con operaciones sobre los campos que va a obtener
Ejemplo:
Select convert(int(campo1)) + fn_funcion_propia(campo2, campo3) from 8. Al escribir un query usando una vista, evita leer una tabla referenciada en la vista
SELECT member_number, first_name, last_name, room_number FROM members, vi_members
WHERE members.room_number = vi_members.room_number ( la vista es:
SELECT member_number, first_name, last_name, room_number FROM members where state = ‘A’
)
Escritura
1. No usar la forma select … into tabla_nombre, se debe primero crear la tabla y luego ejecutar insert into tabla_nombre (campo1,campo2…) select column3, column4 from t2
2. Especifique las columnas a insertar información Dice
Insert into Tabla values (…) Debe decir
Insert into Tabla (campo1, campo2, …) values (…)
Joins
3. Escribe joins en formato ANSI (usa la clausula JOIN .. ON). Con esto te aseguras de escribir todas las restricciones sin posibilidad de olvidarte de alguna restricción
4. Evita usar la misma tabla más de una vez en un solo query. Para mejorar esto, usa tablas temporales
5. Prefiere usar un join en lugar de un sub-query Dice
SELECT member_number, first_name, last_name, room_number FROM members
WHERE room_number IN (SELECT rooms.room_number FROM rooms) Debe decir
SELECT member_number, first_name, last_name, room_number FROM members m
INNER JOIN rooms r ON m.room_number = r.room_number
6. En el caso de que decidas usar queries anidados, siempre califica los campos del subquery con la tabla correspondiente
Manual Buenas Prácticas SQL Server Página 6 de 8 7. En lugar de usar una sentencia con muchos joins donde las tablas involucradas son grandes,
mejor crea una tabla temporal con los datos de la tabla principal (códigos) y luego actualiza esta tabla haciendo joins con las tablas secundarias.
8. En lugar de usar la cláusula IN conjuntamente con un sub-query, usa una sentencia JOIN Dice
SELECT pub_name
FROM dbo.Publishers WHERE pub_id IN
(SELECT Titles.pub_id FROM Titles) Debe decir
SELECT pub_name
FROM dbo.Publishers JOIN dbo.Titles ON Titles.pub_id = Publishers.pub_id
Where
1. Evita usar funciones sobre columnas en la cláusula WHERE Por ejemplo en lugar de usar
SELECT member_number, first_name, last_name FROM members
WHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21 Usa
SELECT member_number, first_name, last_name FROM members
WHERE dateofbirth < DATEADD(yy,-21,GETDATE())
2. Si usas LIKE en la cláusula WHERE, trata de usar por lo menos 3 caracteres adelante como “abc%”
3. Si usas LIKE en la cláusula WHERE, evita usar el operador % al principio: “%abc” 4. Donde sea posible usa la cláusula BETWEEN en lugar de IN
Por ejemplo en lugar de usar
SELECT customer_number, customer_name FROM customer
WHERE customer_number in (1000, 1001, 1002, 1003, 1004) Usa
SELECT customer_number, customer_name FROM customer
Manual Buenas Prácticas SQL Server Página 7 de 8 5. Evita usar concatenaciones en las cláusulas WHERE.
Generales
1. Evite el uso del hardcode
2. Evita usar cursores. En lugar usa tablas temporales con un campo entero identity(1,1) el cual podrás barrer en forma secuencial. No olvides indexar el campo identity.
3. Considera que las funciones MIN y MAX pueden usar índices. Si es posible crea índices sobre las columnas sobre las cuales se usan estas funciones
4. Cuando uses tablas temporales, considera crearles índices para aumentar el desempeño de tus queries.
5. Revisa cada query de un stored procedure y asegurate que no haga “table scan”. Para estudiar esto activa la directiva “Show Query Plan” en el “Query Analyzer”
6. Trata de cada query haga uso de un índice sobre una columna que tenga un alta dispersión. 7. Usa en lo posible tablas derivadas en lugar de tablas temporales. Esto es más razonable si la
información que almacenarías en la tabla temporal las vas a usar una vez. Pero si esta data, la piensas usar muchas veces dentro de un stored procedure, entonces es mejor una tabla temporal.
Por ejemplo en lugar de usar
CREATE TABLE #Temp_Example ( [CategoryID] INT NOT NULL, [Category_Count] INT NOT NULL)
INSERT INTO #Temp_Example (CategoryID, Category_Count) SELECT CategoryID, COUNT(*) AS Category_Count
FROM Categories GROUP BY CategoryID
SELECT C.CategoryID, C.CategoryName, P.ProductName, P.UnitPrice, #Temp_Example.Category_Count
FROM Categories C
INNER JOIN Products P ON C.CategoryID = P.CategoryID
INNER JOIN #Temp_Example ON C.CategoryID = #Temp_Example.CategoryID ORDER BY C.CategoryName
DROP TABLE #Temp_Example Usa
SELECT C.CategoryID, C.CategoryName, P.ProductName, P.UnitPrice, C_Count.Category_Count
FROM Categories C
INNER JOIN Products P ON C.CategoryID = P.CategoryID INNER JOIN (
SELECT CategoryID, COUNT(*) AS Category_Count FROM Categories
GROUP BY CategoryID
)C_Count ON C.CategoryID = C_Count.CategoryID ORDER BY C.CategoryName
Manual Buenas Prácticas SQL Server Página 8 de 8
Transaccionalidad
1. Nunca rompas una transacción en dos transacciones que sean invocadas consecutivamente desde el cliente. Esto hace que si falla segunda transacción, la base de datos quede corrupta. 2. Procura que tus transacciones sean pequeñas, es decir que accedan la menor cantidad de
páginas de la base de datos
3. Evita declarar una sola gran transacción para los procesos en lote. Mejor es tener varias transacciones pequeñas y manejar reprocesos
