MDP Consulting

Manual de Estándares de Programación

SQL SERVER
 Estándares de Programación

Tabla de contenido

1 INTRODUCCIÓN ................................................................................................................................ 1
1.1 Descripción. .................................................................................................... 1
1.2 Objetivo de los Estándares ............................................................................. 1
1.3 Personal Responsable .................................................................................... 1
2 BASE DE DATOS............................................................................................................................... 3
2.1 Políticas Generales ......................................................................................... 3
2.1.1 Pase de Desarrollo a Producción ............................................................... 3
2.2 Test a los Objetos de base de datos............................................................... 5
2.3 Recomendaciones de programación .............................................................. 5
3 DISEÑO DE LA BASE DE DATOS .................................................................................................... 6
3.1 Generalidades ................................................................................................ 6
3.2 Reglas para nombrar Tablas .......................................................................... 8
3.3 Reglas para nombrar Campos ........................................................................ 9
3.4 Reglas para nombrar Procedimientos Almacenados .................................... 10
3.5 Reglas para nombrar Funciones. .................................................................. 11
3.6 Reglas para nombrar Trigger. ....................................................................... 12
3.7 Reglas para nombrar Jobs. ........................................................................... 12
3.8 Reglas para nombrar las VISTAS. ................................................................ 13
3.9 Formato para documentar objetos. ............................................................... 13
4 RECOMENDACIONES ..................................................................................................................... 14
4.1 TIP para programación en T-SQL ................................................................. 17
4.1.1 Lectura ..................................................................................................... 17
4.1.2 Joins......................................................................................................... 17
4.1.3 Where ...................................................................................................... 18
4.1.4 Generales ................................................................................................ 19
4.1.5 Transaccionalidad .................................................................................... 19

Gestión y Administración - TI Página: 2

 Estándares de Programación

1 Introducción

1.1 Descripción.
El presente manual de estándares comprende las normas de estándares técnicos
aplicables al diseño lógico, diseño físico y construcción de la base de datos y sistema
de seguridad bajo el entorno Microsoft SQL y las herramientas de desarrollo
Microsoft Visual Studio.

El contenido del manual ha de ir evolucionando al compás de las necesidades del

desarrollo de aplicaciones, el nivel de implantación de metodologías de desarrollo y
la propia práctica, por lo que su objeto principal es el de ser el documento marco que
en todo momento recoja de forma actualizada las normas que se consideren
aplicables.

Se indica a continuación el contenido el objeto de los estándares, el personal

responsable de cada una de las áreas que se organizan los estándares definidos y
por último, la organización general y las normas tipográficas corrientemente
utilizadas a lo largo del manual.

1.2 Objetivo de los Estándares

El objetivo o propósito de la definición y aplicación de los Estándares son los

siguientes:
 Garantizar la aplicación de un nivel mínimo de calidad en los sistemas de
información.
 Proporcionar un enfoque consistente y un lenguaje común en los entornos con
múltiples equipos de desarrollo.
 Conseguir que los componentes de los sistemas de información sean más
fáciles de entender y mantener.
 Facilitar el proceso de introducción al nuevo personal de desarrollo.

1.3 Personal Responsable

Es responsabilidad de cada uno de los miembros de los equipos de trabajo de

desarrollo la aplicación consecuente de las normas contenidas en este Manual, así
como de su mantenimiento, en función de las nuevas circunstancias o necesidades.
En especial, la correcta interpretación, aplicación y mantenimiento correspondiente,
según las áreas a las siguientes personas:

Administrador de Base de Datos

 Diseño Físico de la Base de Datos
 Índice
 Clusters
 Base de Datos

Gestión y Administración - TI Página: 1

 Estándares de Programación
 Espacio de Tablas
 Segmento de Rollback
 Sinónimos

Analista
 Diseño Lógico de Base de Datos
 Tablas
 Campos
 Restricción de tablas
 Vistas
 Vistas Materializadas
 Secuencias

 Diseño de Módulos de Aplicación

 Modulo
 Parámetros
 Estructura de Datos
 Disparadores
 Uso de Datos
 Interfaces

 Sistemas de Seguridad
 Usuarios
 Grupos y Jerarquías
 Privilegios
 Auditoria
Programador
 Lenguaje T-SQL
 Lenguaje ASP-NET
 Report Services

Gestión y Administración - TI Página: 2

 Estándares de Programación

2 Base de Datos

2.1 Políticas Generales

2.1.1 Pase de Desarrollo a Producción

 El DBA o responsable revisará el cumplimiento de las características

que debe tener cada objeto (definidos en el documento), por ejemplo
formato de nombres, Llaves primarias, relaciones entre tablas, tipos de
datos, entre otros.

 El pase a producción debe ser planificado, si se trata de un módulo

nuevo, informar por medio de un correo al responsable o DBA con al
menos 8 horas de anticipación para realizar un plan para el pase.

 Si se trata de un módulo antiguo, informar por medio de un correo al

responsable o DBA de preferencia al menos con 1 hora de anticipación
e inclusive en forma inmediata, dependiendo de la urgencia para
proceder a evaluar los objetos nuevos creados para registrar en base
de datos.

 Todo objeto de base de datos nuevos que fueron creados sin haber
informado al responsable o DBA, serán borrados sin previa
comunicación, y se procederá a informar al analista de sistemas con
copia a la jefatura por medio de un correo indicando la acción realizada.

 El responsable o DBA está en la obligación de monitorear el

performance de los objetos nuevos creados en producción al menos
por un periodo de 2 semanas, para garantizar la disponibilidad de los
sistemas maximizando los tiempos de respuestas de cara al usuario
final.

 El Analista de Sistemas, antes de solicitar pase a producción está en la

obligación de haber realizado todas las pruebas pertinentes al caso,
revisando cuidadosamente el tiempo de respuesta, errores de
programación, impacto en otros sistemas, entre otros controles que
cada analista cree conveniente realizar.

 Si los objetos nuevos que se pretende pasar a producción no cumple

con lo especificado en el documento, el Analista de Sistema está en la
obligación de realizar los cambios o mejoras sugeridos por el
responsable o DBA.

 Si se trata de objetos antiguos en la base de datos, donde el analista

de sistemas detecta que se usó una mala práctica de programación
(Por ejemplo: SELECT * FROM nombre_tabla), el analista puede
realizar el cambio sin previa comunicación, lo único que debe hacer es

Gestión y Administración - TI Página: 3

 Estándares de Programación
especificar según formato los cambios realizados en el objeto, y se
debe garantizar que la funcionalidad sea la correcta, posteriormente al
DBA le llegará un correo emitido por el server indicando el cambio en
el objeto y este debe estar en la responsabilidad de revisar.

 El pase a producción debe realizarle en las primeras horas del día, de

lunes a viernes de 8 am a 3 pm como máximo, con la finalidad de
garantizar la presencia del analista de sistema en caso exista un
incidente.

 La programación de los procedimiento almacenados, funciones y

Trigger deben mantener un orden en la codificación mediante TABS,
deben de diferenciarse las sentencias uno de los otros y visualmente
agilizar en entendimiento de la lógica implementada.

Ejemplo:

 Evitar la ejecución de querys en el ambiente de producción, para ello

existirá una ambiente de QA con una frecuencia diaria de actualización,
el incumplimiento será informado a la jefatura.

Gestión y Administración - TI Página: 4

 Estándares de Programación

2.2 Test a los Objetos de base de datos

El responsable o DBA está en la obligación de realizar un test a los objetos

que pasaran a producción, el cual deben cumplir las siguientes
especificaciones:

 La ejecución de procedimiento almacenado que sea de tipo INSERT o

UPDATE no debe demorar más de 1 segundo, de preferencia tiene que
ser cero.

 La ejecución de procedimiento almacenado que sea de tipo SELECT no

debe demorar más de 2 segundos, de preferencia tiene que ser cero.

 Si se trata de un procedimiento almacenado que será ejecutado por un

JOBS, y va a ser ejecutado periódicamente en el día, este no debe pasar
de los 3 segundos.

 Si se trata de un procedimiento almacenado que será ejecutado por un

JOBS, y va a ser ejecutado 1 sola vez en el día, este no debe pasar de los
10 segundos y debe ser programado en una hora de la noche, donde la
cantidad de usuarios conectados es mínimo.

 Los objetos de la base de datos deben estar dentro de un ámbito de

negocio (Tabla 002), si el nuevo módulo pertenece a un ámbito que no está
registrado, el DBA está en la obligación de registrar el nuevo dato.

2.3 Recomendaciones de programación

 No utilizar la sentencia "SELECT * FROM NombreTabla", es recomendable

mencionar las columnas que se desea visualizar.

 No se debe realizar un "SELECT COUNT (*) FROM NombreTabla", es

recomendable utilizar la columna de llave primaria para realizar el conteo
("SELECT COUNT (LlavePrimaria) FROM NombreTabla").

 Existen casos donde se realiza una consulta a la misma tabla dentro del
SELECT
 "SELECT columna1, (SELECT columna5 FROM Tabla1 WHERE
columna9=522) as columna5, columna6 FROM Tabla1 columna9=522", es
recomendable utilizarse un LEFT JOIN.

 Para el uso de tablas temporales, la cantidad de los datos que debe albergar
no debe ser mayor a 5000 registros, debido que este objeto hace uso
exclusivamente de la memoria.

 Reducir el uso de cursores, salvo sea el último camino de solución.

Gestión y Administración - TI Página: 5

 Estándares de Programación
 Si el query es una combinación de varias tablas, se debe generar un primer
SELECT con la tabla principal y sacar la cantidad de datos requeridos y
posteriormente proceder a relacionarlos con las demás tablas.

 Los nombres reservados siempre se escribirán en MAYUSCULAS y los

atributos de tablas en MINUSCULAS.

3 Diseño de la base de datos

3.1 Generalidades

Los objetos de base de datos existe una nomenclatura genérica, identificando

el tipo de objeto, el ámbito de negocio y el nombre del objeto.

 Nomenclatura:

<Tipo Objeto>_<Ámbito de Negocio>_<Nombre Objeto>

 Los nombres de objetos de base de datos deben de ser en singular y

en minúscula.

Ejemplo:

tb_ges_cliente, (es errado colocar tb_ges_clientes)

 En caso que el nombre de objeto sea un nombre compuesto, se debe

de usar la nomenclatura camello, este debe iniciar con letra minúscula
y las siguientes palabras iniciar con mayúscula, sin separación alguna.

Ejemplo:

tb_ges_saldoDiario

 Los nombres de objetos no deben de contener artículos o pronombres.

Ejemplo:
La tabla de “Transacciones de clientes” se denominaría de la
siguiente forma:

tb_ges_transaccionCliente

Excluyo el artículo de y cada palabra se colocó en

minúsculas.

Gestión y Administración - TI Página: 6

 Estándares de Programación
 El nombre elegido debe ser lo más descriptivo posible, evitando
términos ambiguos o que se presten a distintas interpretaciones, el
tamaño total del nombre del objeto no debe ser mayor a 32 caracteres.

 Los objetos relacionados deben separase con el símbolo _ y nombrarse

utilizando los nombres de forma invertida, siguiendo un orden lógico de
frase.

Ejemplo:

Tabla “Dirección de Clientes”

tb_ges_cliente_direccion

Relacionada con la tabla tb_ges_cliente

 Salvo de palabras compuestas que se usa la nomenclatura camello

(ejemplo: saldoDiario el espacio en blanco se anula y la siguiente
palabra inicia en mayúscula, no usar el símbolo “_” para separar las
palabras).

Usar el símbolo _ en los nombres de los objetos identifica dependencia.

Ejemplo la tb_ges_cliente_direccion es relacionada con la tabla
tb_ges_cliente y detalla las direcciones del cliente (uno a muchos).

ide
Tipo de Objeto Descripción
Objeto
Tabla destino, cuya fuente es originado
Td SQL Table
de una fuente externa de datos (ETL)
Tabla base de configuración o maestras
Tb SQL Table
internas propias de la aplicación
Tabla agrupadora, originada como un
Ta SQL Table resumen de una/s tabla/s destino, para
una optimizar la emisión de los reportes.
Tabla temporal, usada para almacenar
temporalmente los datos en un
Tt SQL Table procesamiento o generación de reportes,
el contenido puede ser borrado en
proceso de limpieza.
Tabla intermedia, imagen de una tabla
fuente externa, usada para acelerar la
Ti SQL Table
carga y usar procedimientos almacenados
trasformas los datos en proceso de ETL
Tk SQL Table Tablas Backup
Pk SQL Index Índice primario
Ak SQL Index Índice alterno

Gestión y Administración - TI Página: 7

 Estándares de Programación
Tipo de
Objeto SQL Descripción
Objeto
Fk SQL Constraints Índice foráneo
Dg SQL Diagram Diagramas de entidad relación
SQL Store
up Procedimientos Almacenados
Procedure
Fn SQL function Funciones
Jo SQL JOB Jobs de agenda de ejecución
Rp ASP.NET FILE Archivo de reportes (SSRP)
Ap ASP.NET FILE Archivo de programas (aspx)
El ASP.NET FILE Archivo de ETL (SSIS)
Archivo como hojas Excel o archivos
Fi FILE
textos
Sc SQL Script Archivo Script de ejecución de comandos

Ámbito del
Descripción
Negocio
ges Gestión
gen Procedimientos y funciones generales
seg Seguridad
tar Tareas de ejecución de ETL
Sistemas, para uso de documentación y procedimiento
sis generales como utilitarios de desarrollo o
mantenimiento.
ren Rentabilidad
cum Seguimiento de indicadores de cumplimiento
cua Cuaderno de gestión
pre Sistema presupuestal (bifopres)
spr Seguimiento de propuestas
Cualquier otro ámbito de negocios debe estar inscrita en
*
la tabla de tb_seg_aplicacion

3.2 Reglas para nombrar Tablas

Las tablas deben crearse de acuerdo a su representación conceptual en el

ámbito del negocio que permita ordenarlas y facilitar su ubicación, usando la
nomenclatura general definida en el párrafo 3.1:

 La cantidad de Columnas de una tabla no debe ser mayor que 32

columnas, esto permitirá no tener columnas que solo son válidos para
algunos registros y la carga de los datos en una consulta será más
rápida.

 Toda tabla debe tener uno o más campos clave "PRIMARY KEY".

Gestión y Administración - TI Página: 8

 Estándares de Programación

 Los campos clave deben ubicarse al inicio de la definición de la tabla

(deben ser los primeros).

 Toda relación entre tablas debe implementarse mediante constraints

(claves foráneas) con integridad referencial.

3.3 Reglas para nombrar Campos

 Los campos son libres y deberá ser lo más explícito que se pueda, usar guiones
para separar palabras y no excederse del 32 caracteres, no use caracteres
especiales como palabras acentuadas , eñe o símbolos, los nombres deben de
ser en singular.

 Existen prefijos que resumen la primera palabra del campo, son de 3 caracteres
que indican la función del campo y los demás caracteres que expresen el detalle,
siempre escrita con letra minúscula, este estándar debe prevalecer ya que el
mismo será utilizado en el entorno de desarrollo y ayudara a disminuir el tiempo
en el control de seguimiento.

Prefijo Descripción
can Cantidad
cod Código
des Descripción
dir Dirección
est Estado
fec Fecha
grp Grupo
ide Identificador
imp Importe
nom Nombre
num Número
por Porcentaje
tip Tipo
tot Total
var Variación

 Los campos deberán ser de la forma XXX_<campo>, es decir

Ejemplos:

cod_cliente: Código del cliente.

dir_cliente: Dirección del cliente.

Gestión y Administración - TI Página: 9

 Estándares de Programación

3.4 Reglas para nombrar Procedimientos Almacenados

 El nombre del procedimiento almacenado debe indicar con el identificador de

procedimiento up.

 El nombre del procedimiento almacenado debe indicar el ámbito de negocio al

cual el procedimiento está afectando.

 El nombre del procedimiento almacenado debe indicar la acción que este va a

generar, las acciones permitidas son las siguientes:

Prefijo Acción Descripción

sel Listar, Buscar Mostrar un listado de los datos.
cud Crea, Modifica, Elimina Registrar los datos en DB.
Realizar varios procesos, ejemplo
pro Procesar
cálculo de promedios
Mostrar un listado de los datos, que
rep Listar
son fuente para un reporte

Tabla 003: Acciones para los SP

 Si el procedimiento hace referencia a una única tabla, este debe tener el

mismo nombre de la tabla, al cual se le agrega la acción entre en ámbito
de negocio y el nombre.

Ejemplo:

La tabla se llama tb_gen_balanza y vamos a crear el SP para el registro,

el nombre del SP será: up_gen_upd _balanza

 Si el procedimiento hace referencia a varias tablas, el SP debe tener el

ámbito de negocio de la tabla principal, luego se especifica la acción
seguido del nombre de la tabla principal y luego el nombre resumido del
evento.

Ejemplo:

Nos piden visualizar clientes deudores, y la tabla clientes se llama

td_ges_cliente, el SP debe llamarse up_ges_sel_clienteDeudores.

 Existirá algunas excepciones, donde el procedimiento hace referencia a

varias tablas, el SP debe tener el ámbito de negocio "ges", luego se
especifica la acción y luego el nombre resumido del evento de acuerdo a
la interpretación del analista de sistemas.

Ejemplo:

Nos piden visualizar clientes deudores y cuantas facturas emitió, el SP

debe llamarse up_ges_sel_deudaCantidadFactura.

Gestión y Administración - TI Página: 10

 Estándares de Programación

 La cantidad de caracteres del nombre de un SP debe ser menor o igual a

32 caracteres.

 La cantidad de columnas a retornar de un SP debe ser menor o igual a 32

columnas.

 La relación entre palabras en el nombre de un SP tiene que iniciar con

minúscula y no debe estar separado por guiones, la separación de
palabras es con mayúscula (estilo camello).

Ejemplo: up_ges_sel_deudaCantidadFactura.

3.5 Reglas para nombrar Funciones.

 Debe de identificar el ámbito de negocio donde va ser usada la función, si

es una función general, usar el ámbito “gen”.

 En el nombre de una FUNCION se debe indicar la acción que este va a

generar, las acciones permitidas son las siguientes:

Acción Descripción
sel Mostrar un listado de los
datos.
Usado para funciones
SQL tipo Tabla-Valor
cal Retorna un resultado de
una operación.
Tabla 004: Acciones para las Funciones

 El nombre de la función debe empezar con el Prefijo "fn" en minúsculas,

seguido de un guion, se adiciona la acción a generar (cuadro anterior)
y luego se agrega un nombre que describirá con más detalle el evento
y debe empezar con letra mayúscula.

Ejemplo:

Se necesita listar los estados de un campo y es necesario que sea

atreves de una función, el nombre debe ser: fn_ges_sel_estado.

Se necesita realizar la suma de dos números y es necesario que sea

atreves de una función, el nombre debe ser: fn_gen_cal_sumaNumero.

 La cantidad de caracteres del nombre de una FUNCION debe ser

menor o igual a 32 caracteres.

Gestión y Administración - TI Página: 11

 Estándares de Programación
 La cantidad de columnas a retornar de una función debe ser menor o
igual a 16 columnas.

 La relación entre palabras en el nombre de una función tiene que iniciar

con mayúscula y no debe estar separado por guiones.
Ejemplo: fn_gen_cal_sumaNumero.

3.6 Reglas para nombrar Trigger.

 En el nombre de una Trigger se debe indicar la acción en que se va a ejecutar,

las acciones permitidas son las siguientes:

Acción Descripción
ins Se ejecutará cuando se realice un INSERT.
upd Se ejecutará cuando se realice un UPDATE.
del Se ejecutará cuando se realice un DELETE.
cud Se ejecutará cuando se realice un insert, update o
delete.

 El nombre de la Trigger debe empezar con el Prefijo "tr" en minúscula,

seguido de un guion, luego el identificador del ámbito de negocio (el
mismo que usa la tabla), seguido de un guion, luego la acción que
realiza y finalmente el nombre de la tabla (sin el prefijo del negocio).

Ejemplo:

Se necesita crear el Trigger para la tabla tr_ges_balanza cuando se

inserte, el nombre debe ser: tr_ges_ins_balanza.

Se necesita crear el trigger para la tabla tb_vta_factura cuando se

elimine los datos, el nombre debe ser: tr_vta_del_factura.

3.7 Reglas para nombrar Jobs.

 El nombre de un JOBS debe empezar con el Prefijo "jb", seguido de un

guion, y luego agregar el código de la aplicación afecta y finalmente
nombre que describa resumidamente el objetivo del mismo.

Ejemplo:

Se necesita crear el jobs para eliminar los registros nulos de la tabla

tb_vta_factura, el nombre podría ser:
jb_ eliminarRegistroNuloFact.

 La cantidad de caracteres del nombre de un JOBS debe ser menor o

igual a 32 caracteres.

Gestión y Administración - TI Página: 12

 Estándares de Programación

3.8 Reglas para nombrar las VISTAS.

 El nombre de una vista debe empezar con el Prefijo "vw" en minúscula,

seguido de un guion, luego el nombre del ámbito de negocio, y
finalmente el nombre que describa resumidamente el objetivo del
mismo, recuerde que deben de ser en singular.

Ejemplo:

Se necesita crear una vista para listar los registros de los clientes con
factura el nombre podría ser: vw_ges_clienteNuevo.

 La cantidad de caracteres del nombre de una vista debe ser mayor a

32 caracteres.

 La relación entre palabras en el nombre de una vista tiene que iniciar

con minúsculas y no debe estar separado por guiones.

Ejemplo: vw_ges_clienteVinculado

3.9 Formato para documentar objetos.

 Los procedimientos almacenados, funciones y Trigger deben poseer

obligatoriamente un detalle de su razón de existencia, este formato
permitirá saber detalladamente los cambios que se realizaron a los
objetos en el transcurso del tiempo.

 El formato a seguir es la siguiente, y debe estar después de la palabra

as del Objeto.

-- =============================================
-- Author: jmieses
-- Create date: 06/02/2012
-- Description: Actualiza la maestra de Aplicación
-- Updates: 06/02/2013 fcossio @001 Agrego el campo
-- tip_apliccion
-- =============================================

 Se debe especificar en el código del objeto el número de ítem donde

se realizó el cambio o aumento de funcionalidad.

-- INICIO @001
SELECT * FROM tt_ges_prueba
-- FINAL @001

Gestión y Administración - TI Página: 13

 Estándares de Programación

4 Recomendaciones

Las recomendaciones que se muestran a continuación, han sido dadas por el equipo de
Sistemas de Gerencia Total SAC y recogidas por BANBIF:

 La optimización de los programas depende de quién desarrolla el modulo y debe

apoyarse de la sentencia "SET EXPLAIN" para ver el plan de ejecución de los querys.

 Todo cambio sobre la BD (campo, tabla, índice, etc.) deben ser notificados a una
persona encargada o DBA, el cual a su vez notificará al resto del personal, es
recomendable la utilización de un correo para el control.

 Cuando exista la necesidad de borrar todo el contenido de una tabla completamente, se

recomienda utilizar el comando TRUNCATE TABLE nombretable. Para estos casos
NO se debe utilizar el comando "DELETE FROM nombretabla" porque hace un
recorrido secuencial de la tabla para borrarla.

 Integer vs. Smallint. Ventaja: Tamaño de almacenamiento y rango máximo. En el caso

del Integer tiene mayor almacenamiento por ser de 4 bytes mientras que el smallint solo
es de 2 bytes.

 Varchar vs Char. Ventaja: El almacenamiento de un char hace que el motor de BD

rellene de espacios en blanco hasta completar la longitud, en el tipo varchar no se
completa con espacios en blanco.

 Decimal vs Float. Ventajas: Decimal es un tipo de dato propietario del motor, las
operaciones aritméticas con este tipo primero las procesa el motor, luego pasa al
procesador, mientras que las operaciones con un float, integer y smallint lo realiza
directamente el procesador, sin embargo la ventaja de Decimal es la longitud en los
decimales, es decir que ya realiza la función de redondeo al almacenar, por ello es más
usado.

 Creación de índices. Ventajas: Minimizar la cantidad de índices en un tabla optimiza

el acceso a los datos y tiempo de indexación. En una arquitectura de BD primaria y
secundario, cuando ocurre una operación de re indexación, al finalizar, todas las páginas
de índices son puestos en el buffer de replicación para que la BD secundaria las reciba.
Es importante ponerse de acuerdo al momento del diseño de los índices para evitar que
durante la programación se redunde en los índices. Evitar uso de índices con campos
de tipo Char cuya longitud sea grande. Es importante considerar el volumen de
información de la tabla. Es usado en filtros, Joins, Order By, Group By.

 Llaves primarias. Ventajas: Las llaves primarias crean un índice de tipo UNIQUE,
refuerza la integridad de la información. Por definición de integridad las llaves primarias
no aceptan nulos.

 Llaves foráneas. Ventajas: Refuerza la integridad de la información. Se apoya de

índices (tipo duplicado) en las tablas. Al no usar: A muchas llaves foráneas en una tabla,
genera demasiados índices.

Gestión y Administración - TI Página: 14

 Estándares de Programación

 Valores por “default”. Ventajas: Refuerza la integridad de la información haciendo que

sean almacenados valores por defecto y no valores NULOS. El control lo tiene la Base
de datos y no la aplicación.

 Transacciones. Ventajas: Integridad y consistencia de la data, el servidor garantiza

que las operaciones realizadas dentro de los límites de la transacción están completas
en el disco, o en caso de una falla durante su ejecución, la base de datos se
reestablecerá al punto antes de la ejecución de la transacción. El tiempo que se
mantenga el registro actualizado dentro de la transacción debe ser mínimo y así lograr
mayor concurrencia y disponibilidad. Replicación consistente. Al no usar: Al ocurrir una
interrupción de una actualización de datos, no se puede asegurar cuanto de la operación
fue realizada, aun en una operación de un sólo registro, no es posible saber si la data
se actualizó en el disco correctamente, o si los índices involucrados se actualizaron
correctamente. Existe inclusive la posibilidad de dejar las páginas del disco
inconsistentes. En un ambiente replicado no se garantiza que el servidor secundario
refleje los cambios realizados en el servidor principal. En procesos de solo lectura no
utilizar transacciones.

 Transacciones cortas. Ventajas: Mientras menos tiempo se mantenga un registro

bloqueado, mayor disponibilidad de la data para el resto de los usuarios, lo cual implica
mayor nivel de concurrencia. Las transacciones permanecen abiertas por mayor tiempo
en el log de transacciones, retrasando la actividad de respaldo, y por ende menor
disponibilidad de espacio en los logs para escribir más transacciones, provocando esta
transacción un Long Transaction, en cuyo caso el proceso es abortado por el manejador,
y dependiendo de qué tan llenos estén los logs se podría suspender la actividad para el
resto de los usuarios, mientras dicho proceso realiza el rollback.

 Índices. Ventajas: En un ambiente de transacciones en línea, es importante el acceso

directo a la data, el bloqueo de registros en forma individual y su actualización directa
provee de mayor nivel de disponibilidad del resto de los registros. La presencia de
índices puede contribuir a reducir el tiempo de respuesta. Al no usar: Se puede provocar
una lectura secuencial, lo cual no es beneficioso si se trata de un ambiente
transaccional, donde se requiere tiempos de respuestas mínimos.

 Seleccionar las columnas necesarias en una instrucción SELECT. Ventajas: El

manejador tiene la habilidad de leer a través de las páginas de índices cuando las
columnas mencionadas, son las que intervienen en un índice en particular, este tipo de
lectura es la más rápida y eficiente. Al no usar: Los buffers internos utilizados por el
cliente son de un tamaño fijo. Mientras más data se seleccione, más context switch se
requerirá para enviar la data desde el servidor al cliente. El llenar los buffers implica
mayor tráfico entre el cliente y el proceso del servidor, lo cual tiene un impacto directo
en el performance.

 TODO query debe acceder las tablas usando índices (salvo que el SQL decida no
usarlos). Esto implica que TODA tabla, incluyendo a las temporales, debe tener un Índice
Clustered. Opcionalmente se pueden colocar uno más Índices NonClustered.

Gestión y Administración - TI Página: 15

 Estándares de Programación
 En la cláusula WHERE nunca usar Funciones sobre columnas. La función debe estar
sobre la constante con la que se va a comparar.

Ejemplo
No usar: WHERE CONVERT(VARCHAR(10),fec_poliza,121) = "20051201"
Usar : WHERE fec_poliza = CONVERT(DATETIME,"20051201",121)

 En la cláusula WHERE nunca usar operadores con columnas de una tabla. Los
operadores colocarlos sobre la constante con la se va a comparar.

Ejemplo
No usar: WHERE num_poliza + 600 = @variable_poliza
Usar : WHERE num_poliza = @variable_poliza - 600

 Toda tabla temporal debe ser borrada, no deben existir tablas con tt_ en las Bases de
Datos de Producción.

 Cada Stored Procedure debe llevar en la cabecera, el nombre del autor, la fecha y una
breve descripción del objetivo del SP.

 Evitar querys dinámicos concatenando valores separados por comas, como por

Ejemplo:
DELETE FROM td_ges_direccion WHERE cod_direccion IN (#1, #2, #3,..#N)

En lugar de esto colocar los valores en una tabla de tal forma que se pueda hacer
cruces con otras tablas, como por

Ejemplo:

DELETE td_ges_direccion
FROM DIRECCIONES, #tt_ges_temporal
WHERE td_ges_direccion.cod_direccion =
#tt_ges_temporal.cod_direccion

Gestión y Administración - TI Página: 16

 Estándares de Programación

4.1 TIP para programación en T-SQL

4.1.1 Lectura

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

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

 En lugar de SET ROWCOUNT n, usa TOP n.

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

 Evite usar SELECT … INTO table_name. Esto bloqueará 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.

4.1.2 Joins

 Escribe Joins en formato ANSI (usa la cláusula JOIN .. ON). Con esto te aseguras
de escribir todas las restricciones sin posibilidad de olvidarte de alguna restricción.

 Evita usar la misma tabla más de una vez en un solo query. Para mejorar esto, usa
tablas temporales.

 Prefiere usar un Join en lugar de un sub-query.

Por ejemplo en lugar de usar:

SELECT member_number, first_name, last_name, room_number

FROM members
WHERE room_number
IN (SELECT rooms.room_number FROM rooms)

Gestión y Administración - TI Página: 17

 Estándares de Programación

Usa
SELECT member_number, first_name, last_name, room_number
FROM members m
INNER JOIN rooms r
ON m.room_number = r.room_number

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

 En lugar de usar la cláusula IN conjuntamente con un sub-query, usa una sentencia

JOIN.

Por ejemplo en lugar de usar

SELECT nom_publisher
FROM tb_gen_publisher
WHERE cod_publisher IN
(SELECT cod_publisher FROM tb_gen_title)

Usa:

SELECT nom_publisher
FROM tb_gen_publisher
INNER JOIN tb_gen_title
ON tb_gen_title.cod_publisher = tb_gen_ publisher.cod_publisher

4.1.3 Where

 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())

 Si usas LIKE en la cláusula WHERE, trata de usar por lo menos 3 caracteres

adelante como “abc%”

 Si usas LIKE en la cláusula WHERE, evita usar el operador % al principio: “%abc”

 Donde sea posible usa la cláusula BETWEEN en lugar de IN

Gestión y Administración - TI Página: 18

 Estándares de Programación

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

 Evita usar concatenaciones en las cláusulas WHERE

 Evita usar los operadores OR, NOT IN, NOT BETWEEN, <>, NOT EXISTS, NOT
LIKE, LIKE ‘%ABC’

 Si un query tiene uno a más operadores OR, considera reescribir el query en varios
Queries y une los resultados usando el operador UNION. Recuerda de usar
“UNION ALL”, si es posible.

4.1.4 Generales

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

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

 Cuando uses tablas temporales, considera crearles índices para aumentar el

desempeño de tus Queries.

 Revisa cada query de un stored procedure asegúrate que no haga “table scan”
(búsqueda no indexada). Para estudiar esto activa la directiva “Show Query Plan” en
el “Query Analyzer”.

 Trata de cada query haga uso de un índice sobre una columna que tenga una alta
dispersión.

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

4.1.5 Transaccionalidad

Gestión y Administración - TI Página: 19

 Estándares de Programación
 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.

 Procura que tus transacciones sean pequeñas, es decir que acceden a la menor
cantidad de páginas de la base de datos.

 Evita declarar una sola gran transacción para los procesos en lote. Mejor es tener
varias transacciones pequeñas y manejar reprocesos.

 Evita usar transacciones anidadas.

Gestión y Administración - TI Página: 20