Estandares - Programacion - BaseDeDatos - EPBD - V1.2

Oficina de Tecnología de la CÓDIGO: Versión: 1.
0 – 2017
Información: OTI OTI-CIPR-001
“Año del Buen Servicio al Ciudadano”
SERFOR
Estándares de Programación con

Base de Datos
2022
Archivo: Estándares_de_Programación_con_Base_de_Datos_v1_0.doc
Páginas: 19 páginas
Fecha: 27.12.2017
Autor: Equipo de Desarrollo
Versión 1.0
Página 1 de 24
Oficina de Tecnología de la CÓDIGO: Versión: 1.0 – 2017
LISTA DE CAMBIOS
Núm. Fecha Descripción Autores

1 27.12.2017 Versión 1.0. Elaboración Equipo de Desarrollo
2 19.07.2018 Se agrega campos de auditoría para eliminación y se cambia la José Carlos Gallardo
estructura de los nombres de los Procedimientos y/o funciones. Mejía
3 18/12/2018 Se modifica el estándar para nomenclatura de tablas y sus José Carlos Gallardo
columnas Mejía
Página 2 de 24
CONTENIDO
1. ACERCA DEL DOCUMENTO..................................................................................4

1.1 Objetivo............................................................................................................. 4
1.2 Base Legal........................................................................................................4
2. ESTANDARES GENERALES DE NOMENCLATURA.............................................5
2.1 Estándares Generales de Nomenclatura para Base de datos...........................5
2.2 Estándares Generales de Nomenclatura para DDL..........................................6
2.3 Estándares Generales de Nomenclatura para programación............................8
2.4 Prefijos y Sufijos................................................................................................9
3. ESTÁNDARES EN PROCEDIMIENTOS ALMACENADOS...................................10
3.1 General........................................................................................................... 10
3.2 Comentarios y Control de Cambios.................................................................10
3.3 Parámetros......................................................................................................13
3.4 Variables......................................................................................................... 13
3.5 Control de Errores...........................................................................................14
4. REGLAS DE PROGRAMACION PARA MAYOR RENDIMIENTO.........................15
Página 3 de 24
1. ACERCA DEL DOCUMENTO
1.1 Objetivo
Este documento es el Estándar de programación con Base de Datos en el marco de construcción del
Sistema Nacional de Información Forestal y Fauna Silvestre - SNIFFS.
1.2 Base Legal

 Ley N° 28612 que norma la adquisición y uso del software en la Administración Pública.
 Ley N° 28530 “Ley de Promoción de Acceso a Internet para Personas con Discapacidad y de
Adecuación del Espacio Físico en Cabinas Públicas de Internet”.
 D.S. 013-2003 PCM. Dictan medidas para garantizar la legalidad de la adquisición de programas de
software en entidades y dependencias del Sector Público.
 R.M. 126 -2009-PCM, Lineamientos para Accesibilidad a Páginas WEB y Aplicaciones para Telefonía
Móvil para Instituciones Públicas del Sistema Nacional de Informática.
 Norma Técnica Peruana “NTP- ISO/IEC 12207:2006 TECNOLOGÍA DE LA INFORMACIÓN. Procesos
del Ciclo de Vida de Software.
 Guía para la Administración eficiente de Software de la Administración Pública INDECOPI -2004.
 Directiva Nro. 008-2003-INEI/DTNP aprobada con R.J. Nro. 199-2003-INEI. “Normas Técnicas para la
Administración del Software Libre en los Servicios Informáticos de la Administración Pública”.
 Directiva Nro. 016-2001-INEI/DTNP aprobada con R.J. Nro.234-2001-INEI. “Normas y Procedimientos
Técnicos sobre contenidos de las Páginas Web en las entidades de la Administración Pública”.
Página 4 de 24
2. ESTÁNDARES GENERALES DE NOMENCLATURA
Antes de iniciar programación de Base de Datos es necesario definir la interface de programación.

Para RDBMS MS-SQL Server se utilizará el editor de consultas del Business Intelligence Development Studio, el
cual deberá iniciarse teniendo en cuenta:
 Habilite los números de línea para el editor de consultas:
 En el editor de consultas, se utilizará:

o Tabulado equivalente a dos (2) espacios.
o Utilice fuentes de texto de ancho fijo. Se recomienda: Courier New (tamaño 10) o Consolas
(tamaño 10), el tamaño es opcional.
2.1 Estándares Generales de Nomenclatura para Base de datos

 Las bases de datos deben nombrarse siguiendo la siguiente nomenclatura:
 Dependiendo si la base de datos es Institucional o de alguna dirección.
Objeto Sintaxis Ejemplo Comentario

s
Base de SERFOR_BD”<InicialesProyecto>” SERFOR_BDPLANILLAS Nombre

datos debe ser
Institucionale escrito en
s mayúsculas.
Base de <InicialesDirecciòn>_BD”<InicialesProyecto OGAJ_BDPROCESOJUDICIA

datos que >” L
Página 5 de 24
pertenecen a OGAJ: Oficina General de
una Dirección Asesoría Jurídica.
 Los identificadores de las bases de datos no deben contener abreviaturas, pero sí podrían estar formados
por siglas.
 Los identificadores no contendrán prefijos, sufijos ni palabras con tilde.
 Todas las instrucciones propias de SQL se escribirán en mayúsculas
Cada aplicativo que se implemente, deberá tener asignado un usuario de aplicación, el cual debe regirse a la
siguiente nomenclatura:
Objeto Sintaxis Ejemplo

Usuarios <1ra. letra de su nombre> <ApellidoPaterno> <1ra. SI hay un usuario Luis Polay Rossi, entonces su
Personales letra de su ApellidoMaterno (opcional)> usuario sería lpolay, en caso de existir este
usuario en la Bd, entonces se crearìa el usuario
lpolayr
Usuarios de us +“_”+ <iniciales del proyecto> +”_”+ <Nombre de us_sniffs
Aplicación base de datos (opcional)>
2.2 Estándares Generales de Nomenclatura para DDL
 Los identificadores de las bases de datos no deben contener abreviaturas, pero sí podrían estar formados
por siglas.
 Los identificadores no contendrán prefijos, sufijos ni palabras con tilde.
 Todas las instrucciones propias de SQL se escribirán en mayúsculas
 Los nombres de las tablas deberán tener notación pascal, en singular y deben ser sustantivos
descriptivos.
Ejemplo:
Factura, Modulo, PermisoUsuario

 Los nombres de las columnas deberán tener notación pascal, deben ser sustantivos, descriptivos, estar en
singular y no contener abreviaturas (sin guiones bajos).
 No deben incluirse sufijos en los nombres de columnas, salvo casos especiales como los siguientes:
Caso especial Sintaxis de Nomenclatura Descripción Ejemplo
ID usuario quien creó el

Campos de Nu_IdUsuarioRegistro int registro.
auditoría
Página 6 de 24
Fe_FechaRegistro datetime
Fecha cuando se creó el
registro.
Nu_IdUsuarioMod int
ID usuario quien
modificó el registro.
Fe_FechaModifica datetime
Fecha cuando se
modificó el registro.
Nu_IdUsuarioElimina int
ID usuario quien eliminó
el registro.
Fe_FechaElimina datetime
Fecha cuando se eliminó
el registro.
Campos por “Id” + <nombre tabla> Nombre del PK de la IdUsuario

convención tabla.
Siendo un número
autogenerado de la
tabla.
“Cod” + <nombre tabla> Código (cadena) CodEspecie

estandarizado del
Catálogo de Tablas
maestras.
“Nom“+ <nombre tabla> Campo Nombre de NomUsuario

tablas maestras
 Se utilizará la siguiente nomenclatura en la creación de restricciones:
Tipo de restricción Nomenclatura
Clave primaria (PRIMARY KEY) PK_NombreTabla_NombreColumna

Si la clave es compuesta no se consideran los nombres
de las columnas.
Clave Foránea (FOREIGN KEY) FK_ NombreTablaOrigen_ NombreTablaDestino
Valor por defecto (DEFAULT) DF_ NombreTabla_NombreColumna
Regla de validación (CHECK) CK_ NombreTabla _NombreColumna
Valor único (UNIQUE) UQ_ NombreTabla_NombreColumna
Página 7 de 24
Si la clave es compuesta no se consideran los nombres

de las columnas.
 Las longitudes para las columnas de cadena se recomienda que tengan longitudes que sean múltiplos de
8.
 Los índices para cada tabla tendrán la siguiente nomenclatura: IX_ NombreTabla_NombreColumna.
 Si el índice es compuesto no se consideran los nombres de las columnas, se considera un nombre
descriptivo o en su defecto se agrega un correlativo después del nombre de la tabla.
2.3 Estándares Generales de Nomenclatura para la creación de objetos en los

sistemas transaccionales.
2.3.1 Consideraciones generales para la nomenclatura.

 El nombre de un objeto de base de datos deberá estar en singular,
tendrá un máximo de 30 caracteres y no se deberán usar
abreviaciones salvo que este exceda el límite.
 Adicionalmente los nombres sólo pueden incluir caracteres [A-Z] y [0-9]
y separando cada palabra entre guión bajo (_).
 Las letras acentuadas se reemplazarán con las equivalentes no
acentuadas, y en lugar de la letra eñe (Ñ) se utilizará (NI). Ejm:
ANIO_EXPEDIENTE.
 Se debe registrar metadata a la base de datos, agregando comentarios
a las tablas y campos, sobre todo a los booleanos.
2.3.2 Aplicación de estándares a un esquema.

 El nombre tendrá una longitud máxima de 15 caracteres.
 Deberá ser un nombre único en la base de datos que identifique al
aplicativo, el cual será coordinado con el administrador de base de
datos del Serfor.
2.3.3 Aplicación de estándares a tabla.

2.3.3.1. Nomenclatura.
Página 8 de 24
 El nombre de una tabla deberá cumplir las consideraciones generales

descritas en el apartado "2.3.1. CONSIDERACIONES GENERALES
PARA LA NOMENCLATURA”.
 Lo nombres de las tablas seguirán el siguiente formato:
[T]_[XX][Y]_[ZZZZZZZZZZ]
Donde: Descripción
T Prefijo de Tipo de Objeto
Tipo de tabla según su naturaleza, se
XX encuentra compuesto por dos caracteres
Tipo de tabla según su estructura, se
Y encuentra compuesto por un carácter
Nombre representativo de la tabla, se
ZZZZZZZZZZ recomienda que no exceda los 10 caracteres
Los tipos de tabla según su naturaleza
MA MAESTRO
MV MOVIMIENTO
TM TEMPORAL
GE GENERAL
Los tipos de tabla según su estructura
P Plano
C Cabecera
D Detalle
Página 9 de 24
A continuación, algunos ejemplos de las combinaciones entre los tipos de tabla según
su naturaleza y su estructura:
MAP = Maestra Plana
MVC = Movimiento Cabecera
MVD = Movimiento Detalle
TMP = Temporal Plano
Ejemplo
En el caso de que sean tablas provenientes de la relación de dos o más tablas (tablas
relacionadas), se utilizará para nombrarla los nombres descriptivos de las tablas
relacionadas, utilizando una letra “_” para separarlas.
2.3.3.2. Consideraciones para nombrar columnas
El nombre de una columna deberá cumplir las consideraciones generales descritas en
Página 10 de 24
el apartado " 2.3.1. CONSIDERACIONES GENERALES PARA LA NOMENCLATURA ”.

El nombre de una columna debe cumplir el siguiente formato:
Formato: [TD]_[AAA_BB_CCC]
Donde : Descripción
TD Prefijo del tipo de dato almacenado en la columna
AAA_BB_CCC Nombre representativo de la columna. Debe describir el dato
que va a almacenar de manera entendible; si se usan
abreviaturas, éstas deberán ser mnemotécnicas.
Las columnas usadas como flag serán de tipo Char (1) y
nombrarse con una palabra que indique su estado en verdadero.
Las columnas de tipo Fecha y hora deben nombrarse con una
palabra que indique si es Fecha y/u hora
Los tipos de dato (TD) han sido agrupados de la siguiente manera
Nomenclatur
Tipo de dato Contenido a
BINARY Binario BL
IMAGE Binario BL
VARBINARY Binario BL
DATE Fecha FE
DATETIME Fecha FE
DATETIME2 Fecha FE
SMALLDATETIME Fecha FE
TIME Fecha FE
TIMESTAMP Fecha FE
BIGINT Número NU
BIT Número NU
DECIMAL Número NU
Página 11 de 24
FLOAT Número NU
INT Número NU
MONEY Número NU
NUMERIC Número NU
NVARCHAR Número NU
REAL Número NU
SMALLINT Número NU
SMALLMONEY Número NU
TINYINT Número NU
CHAR texto TX
NCHAR texto TX
NTEXT texto TX
TEXT texto TX
VARCHAR texto TX
Ejemplos:
TX_DESCRIPCION
FE_FECHA_REGISTRO
FE_FECHA_DOCUMENTO
Las columnas de tipo llave primaria deben ubicarse al inicio de la definición de la tabla,
además debe cumplir el siguiente formato:
Formato: [TD]_[ID]_[ZZZZZZZZZZZ]
Donde : Descripción
TD Prefijo del tipo de dato almacenado en la columna
ID Prefijo de tipo de columna
Página 12 de 24
ZZZZZZZZZZZ Nombre representativo de la tabla, se recomienda

que no exceda los 10 caracteres
Ejemplo
Tabla : T_MAP_TIPODOCUMENTO
Columna : NU_ID_TIPODOCUMENTO
2.4 Estándares Generales de Nomenclatura para programación
1. Se utilizará la notación Pascal para todos los identificadores objetos de programación de base de datos
(procedimientos almacenados, funciones definidas por el usuario, desencadenadores, etc.)
Ejemplos:
UsuarioLogin, ComprasListar, VentasGenerarReporte
2. La notación Pascal no se aplica a los prefijos o sufijos.
Ejemplo:
pa_FacturaRegistrar, fn_PromedioMensualObtener
3. No se utilizarán abreviaturas en los identificadores.

4. Utilice nombres descriptivos para los identificadores de objeto.
5. Todos los objetos se crearán dentro del esquema propietario dbo (en MS-SQL Server), debiéndose
indicar de manera explícita en la definición del objeto.
Ejemplo:
CREATE PROCEDURE dbo.pa_Usuarios_ListarPorModulo
2.5 Prefijos y Sufijos

 Se utilizarán los siguientes prefijos, en función a la naturaleza del objeto:
Objeto Prefijo
Procedimiento almacenado pa_
Página 13 de 24
Función definida por el usuario fn_
Desencadenador tr_
Vista vs_
Ensamblado en_
 Se utilizarán los siguientes segundos prefijos, en función a la tarea exclusiva a realizar:
Acción Segundo prefijo
Registra datos Registra
Actualiza datos Actualiza
Elimina datos Elimina
Lista datos Lista
Otras operaciones (Nombre que identifique el tipo de operación;

ejemplo: Valida, Genera, etc.)
Nota: estos segundos prefijos se anteponen al identificador propio del objeto.
Ejemplos:
a. Procedimiento almacenado que registra una nueva factura:
CREATE PROCEDURE pa_Factura_Registra
b. Función definida por el usuario que valida un monto de compra
CREATE FUNCTION fn_Contrato_Lista
Página 14 de 24
3. ESTÁNDARES EN PROCEDIMIENTOS ALMACENADOS
3.1 General
 El identificador de un procedimiento almacenado deberá cumplir el siguiente formato:
pa_<IdentificadorObjeto>_<IdentificadorProcedimiento>
Donde
<IdentificadorObjeto> será una expresión, sin abreviaturas, que corresponda con el nombre de la tabla u
objeto sobre la cual se aplica el procedimiento.
<IdentificadorProcedimiento> será una expresión, sin abreviaturas, que describa la tarea llevada a cabo
por el procedimiento.
Ejemplo:
pa_Usuarios_ListarPorModulo
 Utilice las instrucciones BEGIN y END (en MS-SQL Server) para contener el cuerpo del procedimiento
almacenado.
3.2 Comentarios y Control de Cambios

 Cabecera general
Utilice el siguiente formato de cabecera para cada procedimiento, función o bloques de sentencias
programadas en SQL:
-- ***************************************************************************************************** --
-- Nombre : pa_ListarUsuariosPorModulo
-- Descripción: Procedimiento que Inserta los datos de un usuario y ejecuta un trigger de actualización
-- Creado por: Edwin Benavente / 10-10-2013 / Creación del procedimiento
-- @001 Modificado por: Jimmy Velásquez / 10-10-2013 / Se agregó columnas nombre
-- @002 Modificado por: Alex Tantachuco / 12-12-2013 / Se agregó columnas dni y tipo de guía
-- @003 Modificado por: Edwin Benavente / 14-12-2013 / Actualización de tablas maestras (8.3: REQ-0021)
Página 15 de 24
-- ***************************************************************************************************** --
Nota: la sección de modificación deberá ser tratada de la siguiente forma:
a. Utilizar marca de cambios con el formato “@<nro. correlativo>”, para llevar una numeración
correlativa de cada cambio.
b. Nombre Completo y Fecha en una sola línea.
c. Si la modificación la hace el creador, sólo deberá consignarse la fecha y la descripción de
la modificación.
d. Si la modificación la hace otra persona, se consignará el nombre, la fecha y la descripción.
e. En caso se tenga el documento de Especificación de Requerimientos también indicar el
Nro. de Sección y Nro. Requerimiento, entre paréntesis al final de la descripción del
cambio.
f. La sección de modificación se repetirá tantas veces como sea necesario.
 Marca de cambios:
El código del cambio indicado en la Cabecera de Control de Cambios, se replicará enmarcando las
líneas de código afectadas, dentro de bloque I=INICIO, F=FIN.
Por ejemplo:
Cuando sean varias líneas de código:
SELECT
PC.codigo_formula_polinomica_local
, P1.codigo_parametro
, PC.codigo_formula_polinomica_extranjera
, P2.codigo_parametro
, PC.id_partida_cliente
, PC.codigo_clase
...
...
--@0001 - I
CASE WHEN
PAD.rendimiento_factor_equivalencia=0
--@0001 - F
...
...
Página 16 de 24
En caso el cambio esté en una sola línea

CASE WHEN PAD.rendimiento_factor_equiv-alencia=0 --@0001 - I/F
 Comentarios
a. Las líneas de código que ya no son de interés a la lógica programada deberán ser
eliminadas.
b. En el caso que se necesite comentar una línea de código hacerlo de forma breve y
descriptiva.
Por ejemplo:
...
--Obtener Valores Anteriores
DECLARE @id_recurso bigint
DECLARE @id_oferta bigint
3.3 Parámetros
 Los parámetros del procedimiento almacenado tendrán como nombres los mismos nombres de las
columnas de las tablas que representan, así como sus tipos y longitudes.
 Si un parámetro de procedimiento no representa a ninguna columna de tabla se utilizará el tipo de dato
más adecuado en función a los posibles valores que dicho parámetro pueda almacenar. De tratarse de
parámetros de tipo cadena, se recomienda que la longitud sea múltiplo de 8.
 Utilice el siguiente formato para comentar los parámetros:
Nota: las líneas rojas del gráfico indican que debe mantenerse la misma alineación para los tipos de
datos y los comentarios.
Página 17 de 24
3.4 Variables
 Todas las variables serán definidas al inicio del procedimiento y luego del bloque de cabecera. Después
de la palabra reservada BEGIN (en MS-SQL Server).
 Las variables tendrán como nombres los mismos nombres de las columnas de las tablas que
representan, así como sus tipos y longitudes.
 Si una variable no representa a ninguna columna de tabla debe utilizarse el tipo de datos más adecuado
en función a los posibles valores que dicha variable pueda almacenar. De tratarse de parámetros de tipo
cadena, se recomienda que la longitud sea múltiplo de 8.
 Utilice el siguiente formato para comentar las variables:
Nota: las líneas rojas de gráfico indican que se debe mantener la misma alineación para los nombres de
las variables, sus tipos y sus comentarios.
Página 18 de 24
3.5 Control de Errores

Todos los procedimientos almacenados (en MS-SQL Server) deberán estar contenidos en estructuras
de control de error TRY...CATCH. Se considerará que aquellos procedimientos con operaciones simples
no manejarán transacciones dentro del procedimiento.
ALTER PROCEDURE dbo.pa_Ejemplo

AS
BEGIN
BEGIN TRY
SELECT GETDATE()
SELECT 1/0
END TRY
BEGIN CATCH
SELECT
ERROR_NUMBER() AS ErrorNumero,
ERROR_SEVERITY() AS ErrorSeveridad,
ERROR_STATE() AS ErrorEstado,
ERROR_PROCEDURE() AS ErrorProcedimiento,
ERROR_LINE() AS ErrorLinea,
ERROR_MESSAGE() AS ErrorMensaje
END CATCH;
END
Página 19 de 24
4. REGLAS DE PROGRAMACION PARA MAYOR RENDIMIENTO

 Evitar en lo posible el uso de cursores. Tener en cuenta:
o En el caso de ser necesario el uso de cursores, utilice la configuración más adecuada según el
uso que dará al mismo (sólo lectura, sólo avance, etc.).
o Para evitar el uso de cursores, es mejor usar loops con sentencias WHILE, es más rápido; pero
para poder hacer uso de esto es necesario tener definida en la tabla una llave que identifique al
registro (primary key o unique).
Otra opción es crear un contador que recorra un campo identity de la variable tipo “Table“, pero
tener en cuenta que esto genera una sobrecarga adicional en la Base de datos del Tempdb,
restringir su uso para operaciones que duran demasiado en ejecutarse.
 En la programación SQL, tener en cuenta:
o Usar al inicio de los procedimientos almacenados (en MS-SQL Server).
SET ANSI_NULLS ON — asegura comportamiento Ansi Null durante concatenaciones en

operaciones
SET CONCAT_NULL_YIELDS_NULL ON —cualquier concatenación con NULL es NULL
SET NOCOUNT ON — minimiza trafico de red.
o No utilizar “SELECT * “ en las consultas, siempre se deben indicar explícitamente las columnas
que se quieren extraer. Esto reduce el I/O mejorando el performance.
o Evitar el uso de sub-consultas (Subquery) si puede utilizarse en su lugar reuniones (JOINS)
entre resultados. Pero en caso que tenga sentencias SQL complejas y anidados utilizar sub-
consultas después del “FROM”. Evitar sub-consultas cargadas dentro del “SELECT”.
o Evitar el uso de tablas temporales (#nombreTabla) ya que generan más I/O. Considerar
primero el uso de sentencias SQL más avanzados, vistas, como tipo de dato “Table” y tablas
derivadas.
En caso no exista otra manera y/o se tenga un gran número de registros (>50,000 registros)
utilizar tablas temporales.
-- Tipo de dato tabla

DECLARE @TableVar TABLE
(Cola int PRIMARY KEY,
Colb char(3))

Página 20 de 24
INSERT INTO @TableVar VALUES (1, 'abc')

INSERT INTO @TableVar VALUES (2, 'def')

SELECT * FROM @TableVar
GO

--Tabla derivada
SELECT ST.stor_id, ST.stor_name
FROM stores AS ST,
(SELECT stor_id, COUNT(DISTINCT title_id) AS title_count
FROM sales
GROUP BY stor_id
) AS SA
WHERE ST.stor_id = SA.stor_id
AND SA.title_count = (SELECT COUNT(*) FROM titles)
o Si va a utilizar un mismo resultado intermedio más de una vez en una consulta, utilice una
expresión de tabla común (CTE: Common Table Expression). Se recomienda el uso de tablas o
variables temporales.
o Al efectuar reuniones entre tablas, ubique la tabla de menor tamaño a la izquierda de la

expresión. Esto permitirá que se efectúen menos recorridos durante la combinación de filas.
o Utilizar vistas materializadas a demanda o vistas indizadas en lugar de vistas online.
o Se recomienda que en las sentencias de INSERT se debe colocar explícitamente las columnas
a las que se va a insertar.
o Evitar la construcción de consultas dinámicas ejecutadas con sp_executesql.
Página 21 de 24
o Utilizar la instrucción SET para asignar un valor constante a una variable, o para copiar valores
entre variables. No usar SELECT en estos casos.
o Acceder siempre a las tablas en el mismo orden, en todos los Procedimientos Almacenados y
Triggers, de esta manera evitamos generar Deadlocks; así como también mantener las
transacciones lo más pequeñas posibles. Programar según convenga para que las aplicaciones
reintenten la transacción en caso se genere un Deadlock (error 1205).
o Evitar hacer llamado de funciones repetitivamente en los procedimientos almacenados o
Triggers, en lugar de eso hacer el llamado una sola vez y guardarlo en alguna variable.
o Hacer uso de SHOWPLAN_TEXT o SHOWPLAN_ALL para analizar las consultas.
Usar el utilitario “Plan de Ejecución” del Business Intelligence Development Studio (en MS-SQL
Server).
 En la creación de índices tener en cuenta :

o Cada índice creado en la tabla incrementa el tiempo en que se llevan a cabo los Insert, Update
o Delete, por lo que el número de índices en una tabla no deben ser muchos. Se recomienda
usar de 4 a 5 índices, si la tabla es de solo lectura entonces el número de índices se puede
incrementar.
o Mantener los índices lo más pequeño que se pueda, reduciéndolo se reducen el número de I/O
para leerlo.
o Tratar que los índices creados sean sobre campos de tipo enteros y no de tipo caracter.
o Si se crean índices compuestos el orden en que se creen es muy importante. Trata de colocar
primero la columna que sea más selectiva, es decir donde no se repitan mucho los valores y
después la menos selectiva. También tomar en consideración la forma en que se escribe las
consultas (sentencias Where), se deberá mantener el mismo orden del índice agrupado
(clustered).
o Los índices agrupados (clustered) funcionan mucho mejor que los no-agrupados (nonclustered)
si se necesitan hacer consultas sobre un rango de valores o si se necesitan ordenar datos por
medio de GROUP BY u ORDER BY.
o Para tablas que son modificadas con mucha frecuencia (UPDATE, INSERT, DELETE) es
recomendable usar un FILLFACTOR diferente de 0 o 100.
 En sentencias WHERE tener en cuenta:

o Evitar en lo posible el uso de sentencias llamadas non-sargable en los argumentos del 'where'.
Por ejemplo "is null", "or", "<>", "!=", "!>" , "NOT EXIST", "NOT IN", " NOT LIKE" y "LIKE
Página 22 de 24
%500" que aunque no siempre, a menudo impiden que el optimizador use un índice para
ejecutar la búsqueda. En adición, las expresiones que incluyen funciones sobre una columna o
expresiones que tienen la misma columna en ambos lados del operador, son non-sargable.
SELECT LocationID FROM Locations WHERE Specialities LIKE '%pples'
--Recomendado
SELECT LocationID FROM Locations WHERE Specialities LIKE 'A%s'
o Si tienes un query que usa la sentencia 'NOT IN' y ofrece un bajo desempeño, es debido a que
el optimizador tiene que realizar un nested table scan. Se recomienda utilizar alguna de las
siguientes alternativas (en este orden):
- EXISTS o NOT EXISTS
- IN
- Realizar un LEFT OUTER JOIN y chequear con una condición nula.
Nota: Cuando hay opción de escoger entre la sentencia IN o EXISTS, generalmente la

segunda se ejecuta con mayor velocidad.
o Funciones y columnas separadas en la sentencia Where.

Por ejemplo:
- Esta sentencia no tomará el índice:
SELECT id_usuario, nombre, apellido
FROM USUARIO
WHERE datediff(yy,fecNacimiento,GETDATE()) >21
- Aqui aplicamos la recomendación y el índice será utilizado:

SELECT id_usuario, nombre, apellido
FROM USUARIO
WHERE fecNacimiento < DATEADD(yy,-21,GETDATE())
o Redundar en algunos casos los campos del Where para consultas muy pesadas y con alto
tiempo de ejecución.
Siempre que se programe un Join en donde la columna filtrada exista en más de una tabla, se
deberá anexar dicha columna en la cláusula WHERE. De esta manera podemos asegurar que
el optimizador de consultas de SQL Server va a escoger el plan de ejecución más adecuado
-- Query con mayor I/O al disco
SELECT * FROM Orden AS O DetalleOrden JOIN AS OD ON OD.OrderID = O.OrderID

WHERE O.OrderID >= 11000
-- Query óptimo
Página 23 de 24
SELECT * FROM Orden AS O JOIN DetalleOrden AS OD ON OD.OrderID = O.OrderID

WHERE O.OrderID >= 11000
AND OD.OrderID >= 11000
 En la creación física de tablas, tener en cuenta:

o Evitar el uso de campos tipo text, ntext o varchar(max). Si no se tiene que guardar un dato
mayor a 8K utilice char(8000) o varchar(8000).
o Evitar el uso de tipos de datos binary o image dentro de la base de datos. En su caso
almacenar la ruta de los archivos ya que ofrece mejor performance o para versiones iguales o
superiores a MS-SQL Server 2008 utilizar FILESTREAM, siempre probar para cada caso.
o Es preferible usar Constraints para mantener la integridad referencial que los Triggers ya que
son más rápidos. Solo usar Triggers para auditar y validaciones que no se puedan hacer con
Constraints.
 Se recomienda usar el siguiente bloque de código TSQL cuando se vaya a borrar muchos registros por
tabla (normalmente cientos de miles) para que el motor MS-SQL no asuma un bloqueo por tabla sino por
página, al no ser muy grande lo que borra.
--Pruebalo y luego implementalo
SET ROWCOUNT 500
delete_more:
DELETE FROM tbl_depura WHERE fecha < '200600101'
IF @@ROWCOUNT > 0 GOTO delete_more
SET ROWCOUNT 0
Página 24 de 24

Estandares - Programacion - BaseDeDatos - EPBD - V1.2

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Estandares - Programacion - BaseDeDatos - EPBD - V1.2

Cargado por

Copyright:

Formatos disponibles

Oficina de Tecnología de la CÓDIGO: Versión: 1.

Estándares de Programación con

Núm. Fecha Descripción Autores

1. ACERCA DEL DOCUMENTO..................................................................................4

1. ACERCA DEL DOCUMENTO

1.2 Base Legal

2. ESTÁNDARES GENERALES DE NOMENCLATURA

Antes de iniciar programación de Base de Datos es necesario definir la interface de programación.

 Habilite los números de línea para el editor de consultas:

 En el editor de consultas, se utilizará:

2.1 Estándares Generales de Nomenclatura para Base de datos

Objeto Sintaxis Ejemplo Comentario

Base de SERFOR_BD”<InicialesProyecto>” SERFOR_BDPLANILLAS Nombre

Base de <InicialesDirecciòn>_BD”<InicialesProyecto OGAJ_BDPROCESOJUDICIA

pertenecen a OGAJ: Oficina General de

una Dirección Asesoría Jurídica.

Objeto Sintaxis Ejemplo

2.2 Estándares Generales de Nomenclatura para DDL

Factura, Modulo, PermisoUsuario

Caso especial Sintaxis de Nomenclatura Descripción Ejemplo

ID usuario quien creó el

Campos por “Id” + <nombre tabla> Nombre del PK de la IdUsuario

“Cod” + <nombre tabla> Código (cadena) CodEspecie

“Nom“+ <nombre tabla> Campo Nombre de NomUsuario

 Se utilizará la siguiente nomenclatura en la creación de restricciones:

Tipo de restricción Nomenclatura

Clave primaria (PRIMARY KEY) PK_NombreTabla_NombreColumna

Clave Foránea (FOREIGN KEY) FK_ NombreTablaOrigen_ NombreTablaDestino

Valor por defecto (DEFAULT) DF_ NombreTabla_NombreColumna

Regla de validación (CHECK) CK_ NombreTabla _NombreColumna

Valor único (UNIQUE) UQ_ NombreTabla_NombreColumna

Si la clave es compuesta no se consideran los nombres

2.3 Estándares Generales de Nomenclatura para la creación de objetos en los

2.3.1 Consideraciones generales para la nomenclatura.

2.3.2 Aplicación de estándares a un esquema.

2.3.3 Aplicación de estándares a tabla.

 El nombre de una tabla deberá cumplir las consideraciones generales

Los tipos de tabla según su naturaleza

Los tipos de tabla según su estructura

2.3.3.2. Consideraciones para nombrar columnas

El nombre de una columna deberá cumplir las consideraciones generales descritas en

el apartado " 2.3.1. CONSIDERACIONES GENERALES PARA LA NOMENCLATURA ”.

Los tipos de dato (TD) han sido agrupados de la siguiente manera

ZZZZZZZZZZZ Nombre representativo de la tabla, se recomienda

2.4 Estándares Generales de Nomenclatura para programación

UsuarioLogin, ComprasListar, VentasGenerarReporte

2. La notación Pascal no se aplica a los prefijos o sufijos.

3. No se utilizarán abreviaturas en los identificadores.

CREATE PROCEDURE dbo.pa_Usuarios_ListarPorModulo

2.5 Prefijos y Sufijos

Procedimiento almacenado pa_

Función definida por el usuario fn_

 Se utilizarán los siguientes segundos prefijos, en función a la tarea exclusiva a realizar:

Acción Segundo prefijo

Registra datos Registra

Actualiza datos Actualiza

Elimina datos Elimina

Lista datos Lista

Otras operaciones (Nombre que identifique el tipo de operación;

Nota: estos segundos prefijos se anteponen al identificador propio del objeto.

a. Procedimiento almacenado que registra una nueva factura:

CREATE PROCEDURE pa_Factura_Registra