Buenas Practicas de SQL

GERENCIA DE TECNOLOGÍA E INNOVACIÓN
1. OBJETIVO 2
2. IDIOMA DE LOS NOMBRES 2
3. NOMENCLATURA BASE DE DATOS 2
4. SINTAXIS 2
5. TABLAS 3
6. DEFINICIÓN DE CAMPOS 4
7. DEFINICIÓN ÍNDICES 5
8. PROCEDIMIENTOS ALMACENADOS 6
9. PARÁMETROS EN PROCEDIMIENTOS ALMACENADOS 8
10. DEFINICIÓN DE VARIABLE EN PROCEDIMIENTO ALMACENADOS 10
11. CURSORES 10
12. CONSULTAS 10
13. RECOMENDACIONES ADICIONALES 11
14. REFERENCIAS 12
GUÍA ESTÁNDAR Y BUENAS PRACTICAS SQL SERVER
GTEI-GXXXX Versión: 1.0 Fecha: Marzo 2018 Página 1 de 12
1. OBJETIVO
Establecer el estándar para los procesos de diseño y desarrollo de bases de datos SQL de las aplicaciones
creadas en Acciones y Valores (In House).
2. IDIOMA DE LOS NOMBRES

Los nombres de los objetos creados en el sistema gestor de almacenamiento se crea en idioma Español,
teniendo presente usar únicamente números y letras o el carácter guión bajo (_). No se permite el uso del
carácter punto (.).
3. NOMENCLATURA BASE DE DATOS

Defina un nombre de base de datos que se relacione con el nombre de la aplicación. Después del nombre
de la base de datos se agrega uno de los siguientes sufijos:
● Trs: Base de datos Transaccional
● Dwh: Base de datos DataWarehouse
● Log: Base de datos Log
● Mbs: Base de datos Membership Ejemplos: CRMTrs, ConstitucionesWebTrs, AllienDwh
4. SINTAXIS
A continuación, se deben tener en cuenta los siguientes puntos:
● Las palabras reservadas de SQL Server deben ir en mayúscula, algunos ejemplos son:
○ SELECT
○ UPDATE
○ INSERT
○ DELETE
○ LEFT
○ RIGHT
○ NOLOCK
○ WITH (NOLOCK)
○ ON
○ AND
● La selección de columnas debe estar relacionada a la tabla que corresponda, es decir, para evitar
ambigüedad se deben tomar como referencia cada campo por su tabla de origen; esta columna se debe
tener en cuenta por medio de un alias asignada a cada tabla y tomar la base de datos de origen. Ejemplo:
5. TABLAS
Para la denominación de las tablas se debe tener en cuenta la siguiente estructura:
● El nombre de la tabla se debe definir con base en la finalidad de la tabla con un nombre claro e iniciar
con la primera letra en mayúscula. Ejemplo: Personas, Divipola, Agencias.
● Si el nombre de la tabla consta de varias palabras, cada palabra debe Iniciar con mayúscula. Ejemplo:
ComercialAgencia.
● No deben contener espacios, ni caracteres especiales, ni Ñ.
NOTA: UTILICE ADECUADAMENTE LAS VARIABLES TIPO TABLA & TABLAS TEMPORALES
características y diferencias entre una y otra. Variables tipo tabla:@
Su uso en procedimientos almacenados provoca menos re compilaciones. Apuntan a estructuras de
memoria por lo que producen menos consumo de recursos que las tablas temporales. Su contenido no
siempre está en memoria. En caso de que se inserte una cantidad grande de registros esta se almacena en
TEMPDB. El contenido de la variable no es afectado por el comando ROLLBACK. No se pueden generar
al vuelo.
No usan paralelismo (multiple threads) en su plan de ejecución. Su uso para tablas de concurrencia alta o
con una gran cantidad de datos puede afectar su desempeño, siendo este menor en comparación con una
tabla temporal. No se les puede agregar índices. No se les pueden modificar ni truncar una vez creadas.
Tablas temporales:
Se almacenan automáticamente en la base de datos TEMPDB. Su creación puede ocasionar bloqueos en
las tablas sysobjects, sysindexes y afectar a todo el servidor. Permite el uso de índices. Su uso en
procedimientos almacenados puede provocar una re compilación continua.A grandes rasgos, pueden
tratarse como una tabla normal. En general, se puede sugerir el uso de variables tipo tabla siempre que sea
posible en lugar de tablas temporales. Use estas últimas solo en caso de que se maneje una cantidad muy
grande de información y siempre procurando crear su estructura previamente
6. DEFINICIÓN DE CAMPOS
● No se pueden almacenar datos NULOS. Siempre se debe almacenar un valor en los campos.
● Usar el tipo de datos NCHAR para una columna solamente cuando no pueda contener valores nulos. Si
una columna NCHAR puede contener valores nulos, es tratada como una columna de ancho fijo. Así que
un NCHAR (100) cuando sea nulo ocupará 100 bytes, resultando en un desperdicio de espacio. Para esta
situación es mejor usar NVARCHAR(100). Ciertamente las columnas de ancho variable tienen un poco
más de sobrecarga de procesamiento en comparación con las columnas de ancho fijo. Se debe escoger con
cuidado entre NCHAR y NVARCHAR dependiendo del ancho de los datos que se van a almacenar, No
utilizar tipos de de datos CHAR y VARCHAR
● Utilizar NCHAR para almacenar un carácter.
● 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.
● También existen muchos errores asociados con la replicación de tablas que contienen columnas de tipo
TEXT. Por eso, si no se necesita almacenar más de 8 KB de texto, es preferible usar los tipos de datos
NCHAR (8000) o NVARCHAR (8000).
● Los archivos de las aplicaciones no se deben almacenar en la base de datos. Preferible almancer la ruta
de los archivos como una valor en un campo de la columna.
● Todos los campos de auditoría inician con el predecesor “Aud_”.
Para los nombres de campo el esquema es el siguiente:
● Las columnas llave primaria siempre se debe llamar Id.
● Siempre deben estar los campos llamados tal y como están definidos a continuación:
○ Id
○ Nombre
○ Codigo
○ Aud_FechaIngreso datetime //Campo de auditoría
○ Aud_UsuarioIngreso nvarchar(256) //Campo de auditoría
○ Aud_FechaActualizacion datetime //Campo de auditoría
○ Aud_UsuarioActualizacion nvarchar(256) //Campo de auditoría
● Los nombres de las columnas deben estar en singular. Ejemplos: Nombre, Codigo.
● Si el nombre de la columna consta de varias palabras, cada palabra debe Iniciar con mayúscula.
Ejemplo: CorreoElectronico
● Los campos llave foránea deben iniciar con el nombre de la tabla padre seguido del carácter “_” y
termina con las letras Id. Ejemplos: Persona_Id, Empresa_Id.
● Si una tabla contiene más de una llave foránea de la misma tabla se debe seguir el estándar añadiendo al
final una palabra clave. Ejemplo: CiudadOrigen_Id, CiudadDestino_Id.
7. DEFINICIÓN ÍNDICES
● Si se usa un gran número de índices en una tabla, el rendimiento de las instrucciones INSERT,
UPDATE, DELETE, MERGE se verá afectado, ya que todos los índices deben ajustarse adecuadamente a
medida que cambian los datos de la tabla. Por ejemplo, si una columna se usa en varios índices y ejecuta
una instrucción UPDATE que modifica datos de esa columna, se deben actualizar todos los índices que
contengan esa columna, así como la columna de la tabla base subyacente (índice de montón o clúster).
● Evite crear demasiados índices en tablas que se actualizan con mucha frecuencia y mantenga los índices
estrechos, es decir, defínalos con el menor número de columnas posible.
● Utilice un número mayor de índices para mejorar el rendimiento de consultas en tablas con pocas
necesidades de actualización, pero con grandes volúmenes de datos. Un gran número de índices
contribuye a mejorar el rendimiento de las consultas que no modifican datos, como las instrucciones
SELECT, ya que el optimizador de consultas dispone de más índices entre los que elegir para determinar
el método de acceso más rápido.
● La indización de tablas pequeñas puede no ser una solución óptima, porque puede provocar que el
optimizador de consultas tarde más tiempo en realizar la búsqueda de los datos a través del índice que en
realizar un simple recorrido de la tabla.De este modo, es posible que los índices de tablas pequeñas no se
utilicen nunca; sin
embargo, sigue siendo necesario su mantenimiento a medida que cambian los datos de la tabla.
● Utilice el Asistente para la optimización de motor de base de datos para analizar las bases de datos y
crear recomendaciones de índices.Para obtener más información, vea Asistente para la optimización de
motor de base de datos.
● Utilice una longitud corta en la clave de los índices clúster. Los índices clúster también mejoran si se
crean en columnas únicas o que no admitan valores NULL.
● Las columnas con tipos de datos ntext, text, image, varchar(max), nvarchar(max) y varbinary(max) no
se pueden especificar como columnas de clave de índice. Sin embargo, los tipos de datos varchar(max),
nvarchar(max), varbinary(max) y xml pueden participar en un índice no clúster como columnas de índice
sin clave.
● Se debe Indicar que index se crea para que sea agregado a los trabajos de Estadísticas e Indexación
NOTA:(Es aconsejable que los índices se formen sobre los campos que encuentren frecuentemente en
alguno de los siguientes escenarios: Son PRIMARY KEY o FOREIGN KEY. Se usan frecuentemente
para enlazar tablas con JOIN. Se usan de forma habitual dentro de los procedimientos almacenados o en
consultas emparejados con alguno de los siguientes comandos: TOP, DISTINCT (Aunque ya
mencionamos que estos deben de evitarse en lo posible, si no hay otra alternativa, hay que considerar sus
campos para la aplicación de índices). Son de uso corriente para filtrados en la cláusula WHERE.)
8. PROCEDIMIENTOS ALMACENADOS
Los procedimientos almacenados deben tener el siguiente estándar:
● Se debe evitar lógica de negocio dentro de un procedimiento almacenado, esta deberá ser implementada
en componentes de la aplicación.
● No usar el prefijo “sp_” para etiquetar procedimientos almacenados. SQL Server reconoce el prefijo
“sp_” como System Stored Procedure. Este detalle en particular apoya en la forma que SQL Server usa
para localizar el procedimiento almacenado cuando se intenta ejecutar. Cómo se trata de un
procedimiento almacenado de sistema, y por lo tanto deberá estar en la base de datos MASTER, donde se
ubican todos los procedimientos almacenados de esta clase. Por tanto se intentan en primer lugar localizar
el procedimiento en la base de datos MASTER. Al no encontrarlo continúa la búsqueda de la base de
datos activa, provocando con esto una caída del rendimiento que influye significativamente en un
ambiente donde se ejecuten miles de transacciones por minuto.
● Ordenar el código fuente del programa para mejorar la legibilidad por parte de los programadores, esto
implica:
○ Escribir en mayúscula las palabras reservadas de SQL Server
○ Registrar en una línea cada campo de la Tabla que se retorna en el SELECT. Este debe estar en un nivel
de sangría mayor al de la instrucción SELECT.
○ Cada instrucción para relación de tablas se debe registrar al inicio de una nueva línea.
○ La instrucción WHERE debe estar en una línea, mientras las condiciones para esta instrucción se
observarán en una nueva línea.
● Los operadores lógicos como AND, OR, etc. deben quedar al inicio de la línea y la siguiente condición
deberá iniciar en una nueva línea.
● Los nombres de los procedimientos almacenados deben estar en letras minúsculas y en singular.
● El nombre del procedimiento almacenado debe iniciar con el tipo de procedimiento almacenado.
● El tipo identifica cuál es la función y objetivo del mismo. A continuación, se especifican los tipos a
utilizar:
○ crud: Procedimiento almacenado el cual identifica que realiza las operaciones de: create, read, update y
delete, estas operaciones siempre se deben manejar en un mismo procedimiento almacenado y no deben
estar independientes. Inicia con la palabra crud luego se separa con el carácter “_”, luego el nombre del
procedimiento. Ejemplo: crud_Persona. La instrucción delete, corresponde a una instrucción de
UPDATE, y actualiza el registro para que no visualice al usuario (Interpretarse como inactivar el
registro).
○ list: Procedimiento almacenado utilizado para devolver consultas de tablas, inicia con la palabra list
luego se separa con el carácter “_”, luego el nombre del componente de aplicación que recibe el objeto o
lo que se quiera expresar. Ejemplo: list_PersonaResultado
○ get: Procedimientos almacenados utilizados para devolver resultados de operaciones o consultas que
devuelvan un único valor, debe iniciar con la palabra get luego se separa con el carácter “_” y sigue con la
función o nombre de los que se quiere expresar. Siempre se debe emplear la instrucción SELECT al
utilizar los procedimientos get_ . Ejemplo get_NumeroDePersonas devuelve el total de personas de la
tabla persona.
● Incluir en el código la instrucción SET NOCOUNT ON. Esta instrucción evita que se devuelva el
mensaje que muestra el recuento del número de las filas afectadas por una instrucción o un procedimiento
almacenado como parte del conjunto de resultado. Se evita que consultas "escondidas" interfieran en el
conjunto de resultados esperados. Con esto evitamos que el SQL Server envíe información de los
resultados que produce tras cada instrucción, lo que puede llegar a aliviar la carga a la que es sometida el
servidor o la red en la cual está actuando.
● Incluir las instrucciones para validar la existencia de los objetos de la base de datos, no se deben
modificar, siempre se deben eliminar y crear nuevamente.
● Incluir los bloques BEGIN y END.
● Todos los procedimientos almacenados deben tener un comentario como el que se describe a
continuación:
9. PARÁMETROS EN PROCEDIMIENTOS ALMACENADOS

Los procedimientos almacenados deben contener los parámetros tanto de entrada como de salida
dependiendo el tipo de procedimiento que se haya definido, a continuación, se detallan:
● CRUD: Para el tipo de procedimiento almacenado CRUD se deben definir los parámetros de la
siguiente manera:
○ Parámetros de Entrada Datos: Se deben llamar de la misma forma que están en la tabla precedido del
carácter “@”
Se debe definir un parámetro de entrada llamado @Aud_FechaActualizacionOriginal de tipo datetime el
cual va a realizar la validación de simultaneidad, esto con el fin de que cuando se realice la actualización
de la información que originalmente se envió al aplicativo no existe un cambio sobre el registro.
● Parámetros de Entrada: Se deberá definir un parámetro llamado @Accion del tipo entero, este
parámetro es el encargado de definir qué acción va a realizar dentro del procedimiento almacenado:
○ 1 = Create (Insert de los datos recibidos a la tabla definida)
○ 2 = Read (Select de los campos de la tabla)
○ 3 = Update (Actualización de la información con los datos recibidos)
○ 4 = Delete (Borrado lógico de la información, interprétese como inactivar el registro)
● Parámetros de Salida: Los parámetros de salida están definidos de la siguiente manera:
○ @Error = Parámetro donde se almacena el valor de @@ERROR
○ @Identidad: Parámetro donde se almacena el SCOPE_IDENTITY()
● LIST: A continuación, se detallan los parámetros para el tipo de procedimientos almacenado llamados
list de la siguiente manera:
● Parámetros de Entrada
○ @PaginaActual y @RegistrosPagina: Determinan la cantidad de registros que deben ser seleccionados
en la operación matemática (@RegistrosPagina * (@PaginaActual - 1)) que se debe almacenar en una
variable definida dentro del procedimiento almacenado, la que en realidad se debe usar para extraer la
cantidad de registros.
● @Orden: Define el campo por el cual se debe realizar el ordenamiento de la consulta.
● Los parámetros de búsqueda o filtro de la consulta deben definir claramente qué se almacena en ese
parámetro, cada palabra debe iniciar con mayúscula, si el nombre del parámetro consta de varias palabras,
cada palabra debe iniciar con mayúscula.
● Parámetros de Salida
○ @TotalRegistros: En este parámetro debe almacenar la cantidad de registros encontrados.
○ @Error = Parámetro donde se almacena el valor de @@ERROR.
● GET: A continuación, se detallan los parámetros para el tipo de procedimientos almacenado llamados
get de la siguiente manera:
● Parámetros de Entrada
○ Los parámetros de búsqueda o filtro de la consulta deben definir claramente qué se almacena en ese
parámetro, cada palabra debe iniciar con mayúscula, si el nombre del parámetro consta de varias palabras,
10. DEFINICIÓN DE VARIABLE EN PROCEDIMIENTO
ALMACENADOS
Las variables dentro de un procedimiento almacenado deben definir claramente qué se almacena en esa
variable, cada palabra debe iniciar con mayúscula, si el nombre de la variable consta de varias palabras,
11. CURSORES
No está permitido el uso de cursores.
12. CONSULTAS
● La instrucción SELECT debe solo recuperar los datos necesarios. El SELECT siempre debe indicar los
campos a retornar.
● No se deben usar alias para las tablas.
● No usar la instrucción SELECT *. Siempre que se utiliza SELECT * todas las columnas en la tabla o
unión 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.
● Si la instrucción SELECT retorna campos iguales para tablas diferentes se debe generar un alias con el
nombre de la tabla y campo
● Siempre llamar procedimientos almacenados. No hay que enviar declaraciones SELECT, INSERT o
UPDATE a la base de datos; en vez de eso, siempre hay que llamar procedimientos almacenados
pasándole los parámetros correspondientes.
● Escribir las consultas con estructuras ANSI en lugar de escribirlas con estructura T-SQL.
● Emplear la siguiente instrucción para las relaciones entre las tablas INNER JOIN
● Cuando se utilizan varias tablas en la consulta, hay que especificar siempre a que tabla pertenece cada
campo.
● Parámetros de Salida
○ @Error = Parámetro donde se almacena el valor de @@ERROR.
● En lo posible utilizar la cláusula BETWEEN en lugar de la cláusula IN en la condición de la instrucción
WHERE.
● Utilizar lo menos posible las siguientes cláusulas: ANY, SOME, IN (SELECT), NOT, IS NULL, !=,
<>, !>, !<, NOT EXIST, NOT IN, NOT LIKE, LIKE ‘%texto’
● No utilizar tablas temporales públicas o globales, es decir, aquellas tablas temporales declaradas
comenzando con los caracteres ## que pueden ser observadas por los usuarios conectados a SQL.
● Utilizar la instrucción TOP para obtener una cantidad limitada de registros.
● Usar la cláusula EXISTS en lugar de la cláusula IN. La cláusula EXISTS es más rápida.
● No utilizar la instrucción ROUND, LOWER, UPPER, SUBSTRING en el WHERE.
● Reemplazar COUNT(*) por COUNT(1) o COUNT(<Nombre del campo>).
● Se debe colocar el esquema correspondiente a la tabla que se defina.
● Utilizar CASE de tal modo de suplir la necesidad de usar código dinámico (código que se almacena en
una variable, frecuentemente NVARCHAR, para ejecutar una instrucción). La sentencia CASE se emplea
para brindar un tipo de lógica “si-entonces” para SQL Server.
● El uso de NOLOCK puede mejorar considerablemente la velocidad de algunas consultas. Al usar
NOLOCK en las consultas se establece que la lectura no “atrapa” la tabla y esta puede ser leída al mismo
tiempo por todos los usuarios. Sin embargo, hay que tomar en cuenta que el conjunto de datos mostrados
es considerado como una “lectura sucia”. No se puede usar NOLOCK de forma indiscriminada en todas
los Procedimientos Almacenados, es más una cuestión de evaluación sobre escenarios particulares. NO
LOCK permite la consulta de información no consolidada (not commited) de una tabla. Al hacer esto la
tabla es consultada al instante sin importar los bloqueos existentes sobre ella, obteniendo una ventaja en el
rendimiento y disponibilidad de la información. Esto conlleva un riesgo. Si una transacción en curso
sobre una tabla falla, por ejemplo un update sobre un campo de Estado, que establece el valor Activo para
200 registros, y si se ejecuta una consulta NO LOCK justo antes de la ocurrencia del fallo (digamos
cuando se habían procesado 199 registros), la consulta WITH(NO LOCK) mostrará los 199 registros con
un Estado Activo, pero la transacción fue descartada, ante el fallo se disparó un rollback, y realmente la
tabla no contiene ningún registro Activo. Por lo tanto, si no se tiene precaución sobre el uso de NO
LOCK, se corre el riesgo de obtener información falsa, registros fantasmas que pueden generar un error
grave en la lógica del negocio. Explicación detallada.
13. RECOMENDACIONES ADICIONALES

Si el procedimiento almacenado contiene demasiadas sentencias IF-ELSE para ejecutar distintos procesos
acorde a ciertos parámetros, resulta más eficiente separar cada bloque y encapsularlos en procedimientos
almacenados diferentes; Esto para evitar que el plan de
ejecución cambie acorde al valor del resultado de la expresión IF, desperdiciando con esto la ventaja de el
plan de ejecución en memoria y la pre compilación.
Evite el uso de la instrucción SELECT-INTO. Al ejecutarse se bloquean las tablas involucradas. Aplique
en su lugar la sentencia INSERT INTO-SELECT.
Trate de usar siempre la instrucción JOIN antes que cualquier subconsulta.
Use la instrucción BETWEEN en lugar de IN siempre que sea posible.
En el caso de que se use la instrucción LIKE, evite el uso del comodín “%” al inicio de la cadena a
buscar. Esto debido a que si se aplica, la búsqueda tendría que leer todos los datos de la tabla o tablas
involucradas para responder a la consulta. Se recomienda que existan al menos tres caracteres antes del
comodín.
Evite en la medida de lo posible el uso de DISTINCT
En caso de usar la instrucción UNION y existiera la seguridad de que en los SELECT involucrados no se
obtendrán registros duplicados, entonces lo recomendable en este escenario es sustituir UNION por
UNION ALL para evitar que se haga uso implícito de la instrucción DISTINCT, ya que esta aumenta el
consumo de recursos.
No use columnas con tipos de datos FLOAT, REAL o DATETIME como FOREIGN KEY.
14. REFERENCIAS
http://eaaranguizb.blogspot.com.co/2013/02/tips-buenas-practicas-sql.html
https://sites.google.com/site/lagaterainformatica/home/-net/sql/-buenas-practicas-sql-server
https://msdn.microsoft.com/es-es/library/dn168156.aspx
http://csharpalextremo.blogspot.com.co/2012/08/mejores-practicas-sql-server.html
https://msdn.microsoft.com/es-es/library/jj835095(v=sql.120).aspx

Buenas Practicas de SQL

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Buenas Practicas de SQL

Caricato da

Copyright:

Formati disponibili

GERENCIA DE TECNOLOGÍA E INNOVACIÓN

2. IDIOMA DE LOS NOMBRES

3. NOMENCLATURA BASE DE DATOS

9. PARÁMETROS EN PROCEDIMIENTOS ALMACENADOS

13. RECOMENDACIONES ADICIONALES

Potrebbero piacerti anche