Manual Buenas Prácticas Codificación SQL Server

Manual Buenas Prácticas Codificación SQL Server

MANUAL DE REFERENCIA

v. 1.0

MANUAL BUENAS PRÁCTICAS CODIFICACIÓN SQL Server ÁREA: ARQUITECTURA DE SISTEMAS

Misión : “Facilitar a las áreas de negocio de la compañía la mejora continua de sus procesos, a través de solucionestecnológicas mediante un equipo de trabajo altamente calificado y comprometido con la organización”

Historia de Revisión

Fecha Versión Descripción Autor

1.0 Creación del Manual Ricardo Larriega

06/11/2012 1.1 Actualización Luis Marcilla Félix

Manual Buenas Prácticas SQL Server Página 2 de 8



ContenidoHistoria 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




ObjetivoRevisar estrategias y lineamientos a seguir para lograr un mejor desarrollo de aplicaciones en plataforma SQL Server.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 Nomenclatura1. 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:*************************************************************/

Lectura1. 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

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 tablas7. 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_numberFROM members, vi_membersWHERE members.room_number = vi_members.room_number( la vista es:SELECT member_number, first_name, last_name, room_numberFROM members where state = ‘A’)

Escritura1. 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ónDiceInsert into Tabla values (…)Debe decirInsert into Tabla (campo1, campo2, …) values (…)

Joins3. 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ón4. Evita usar la misma tabla más de una vez en un solo query. Para mejorar esto, usa tablas

temporales5. Prefiere usar un join en lugar de un sub-query

DiceSELECT member_number, first_name, last_name, room_numberFROM membersWHERE room_number IN (SELECT rooms.room_number FROM rooms)Debe decirSELECT member_number, first_name, last_name, room_numberFROM members mINNER 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 correspondienteSELECT member_number, first_name, last_name, room_numberFROM membersWHERE 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 JOINDiceSELECT 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

Where1. Evita usar funciones sobre columnas en la cláusula WHERE Por ejemplo en lugar de usar

SELECT member_number, first_name, last_nameFROM membersWHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21

Usa

SELECT member_number, first_name, last_nameFROM membersWHERE 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_nameFROM customerWHERE customer_number in (1000, 1001, 1002, 1003, 1004)

Usa

SELECT customer_number, customer_nameFROM customer




WHERE customer_number BETWEEN 1000 and 1004

5. Evita usar concatenaciones en las cláusulas WHERE.

Generales1. Evite el uso del hardcode2. 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 funciones4. 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_CountFROM CategoriesGROUP BY CategoryID

SELECT C.CategoryID, C.CategoryName, P.ProductName, P.UnitPrice, #Temp_Example.Category_CountFROM Categories CINNER JOIN Products P ON C.CategoryID = P.CategoryIDINNER JOIN #Temp_Example ON C.CategoryID = #Temp_Example.CategoryIDORDER BY C.CategoryName

DROP TABLE #Temp_Example

Usa

SELECT C.CategoryID, C.CategoryName, P.ProductName, P.UnitPrice, C_Count.Category_CountFROM Categories CINNER JOIN Products P ON C.CategoryID = P.CategoryIDINNER JOIN ( SELECT CategoryID, COUNT(*) AS Category_Count FROM Categories GROUP BY CategoryID




)C_Count ON C.CategoryID = C_Count.CategoryIDORDER BY C.CategoryName

8. Si vas a actualizar insertar o eliminar muchísimos registros en una sola sentencia, mejor hazlo en partes pequeñas.

Transaccionalidad1. 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 datos3. Evita declarar una sola gran transacción para los procesos en lote. Mejor es tener varias

transacciones pequeñas y manejar reprocesos4. Evita usar transacciones anidadas.


Manual Buenas Prácticas Codificación SQL Server

Documents

Transcript of Manual Buenas Prácticas Codificación SQL Server