Manual Buenas Prácticas Codificación SQL Server MANUAL DE REFERENCIA. v. 1.0

Transcripción

1 Manual Buenas Prácticas Codificación MANUAL DE REFERENCIA v. 1.0

2 Historia de Revisión MANUAL BUENAS PRÁCTICAS CODIFICACIÓN Fecha Versión Descripción Autor 1.0 Creación del Manual Ricardo Larriega 06/11/ Actualización Luis Marcilla Félix Manual Buenas Prácticas Página 2 de 8

3 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... 8 Manual Buenas Prácticas Página 3 de 8

4 Objetivo Revisar estrategias y lineamientos a seguir para lograr un mejor desarrollo de aplicaciones en plataforma. 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 error 5. 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 Página 4 de 8

5 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 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 FROM members, vi_members WHERE members.room_number = vi_members.room_number ( la vista es: 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 FROM members WHERE room_number IN (SELECT rooms.room_number FROM rooms) Debe decir 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 Página 5 de 8

6 FROM members WHERE room_number IN (SELECT rooms.room_number FROM rooms) 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 WHERE customer_number BETWEEN 1000 and 1004 Manual Buenas Prácticas Página 6 de 8

7 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 Página 7 de 8

8 8. Si vas a actualizar insertar o eliminar muchísimos registros en una sola sentencia, mejor hazlo en partes pequeñas. 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 4. Evita usar transacciones anidadas. Manual Buenas Prácticas Página 8 de 8