Estándar de Base de Datos
February 21, 2023 | Author: Anonymous | Category: N/A
Short Description
Download Estándar de Base de Datos...
Description
Estándar de Base de Datos Nombre del Proyecto Versión 1.0
Código o Nombre del Proyecto Software Factory
Versión 1.0 Página 2 de 18 Fecha:28/04/2014
Estándar de Base de Datos
Control de Cambios Control de Cambios y Evolución del Documento Versión
Fecha de Cambio
Fecha de actualización:
Creado por
19/02/14
Revisado Por
Págs.
Página:
Resumen del Cambio
: 2 de 18
Código o Nombre del Proyecto Software Factory
Estándar de Base de Datos
Versión 1.0 Página 3 de 18 Fecha:28/04/2014
Tabla de Conten Contenidos idos 1. INTRODUCCIÓN ............................................................................................... 4 2. OBJETIVOS ...................................................................................................... 4 3. ESTÁN ESTÁNDA DAR R DE NOMENCLATURA NOMENCLATURAS S ................................ ..................... ..................... ..................... ...................... ............. 5 3.1 Nombre de Base de Datos ....................................................................... 5 3.2 Tablas ..................................................................................................... 5 3.3 Campos ................................................................................................... 6 3.4 Constraints .............................................................................................. 7 3.5 Funciones ................................................................................................ 9 3.6 Triggers ................................................................................................... 9 3.7 Procedimientos Almacenados .................................................................. 9 3.8 Vistas .................................................................................................... 10 4. ESTÁNDAR DE DISEÑO ................................................................................. 11 4.1 4.2 4.3 4.4 4.5 4.6
Collation de Base de Datos .................................................................... 11 Encabezado de scripts ........................................................................... 11 Tablas y Campos ................................................................................... 12 Variables Varia bles de Tipo Tabla y Tablas Temporales Temporales ...................... ........... ..................... ................... ......... 12 Procedimientos Almacenados ................................................................ 14 Generación de Consultas ....................................................................... 15
Fecha de actualización:
19/02/14
Página:
: 3 de 18
Código o Nombre del Proyecto Software Factory
Versión 1.0 Página 4 de 18 Fecha:28/04/2014
Estándar de Base de Datos
1. Introducción A lo largo del ciclo de vida de desarro desarrollo llo de un softw software are es necesario asegurar la calidad del mismo. Uno de los instrumentos que facilitan esta tarea es la adopción de estándares de base de datos. Consideramos que la adopción de estándares en el diseño de bases de datos, tiene muchas ventajas, entre ellas: Asegurar la legibilidad del modelo de datos, inclus inclusive ive para personas que no están
relacionadas con el ambiente informático, en etapas de análisis y diseño. Facilitar la portabilidad entre motores de bases de datos, plataformas y aplicacion aplicaciones. es.
Facilitar la tarea de los programadores en e ell desarr desarrollo ollo de sistemas.
Es este sentido que los objetos (tablas, campos, procedimientos almacenados, Triggers, etc.) de base de datos a construirse deben cumplir con ciertas características que detallaremos en el presente documento.
2. Objetivos Establecer el estándar de Base de datos a ser aplicado en todos los desarrollos de
Sistemas de TechEra, buscando de esta forma que todos los sistemas que se desarrollen cuenten con características similares a pesar que sean desarrollados para empresas diferentes. La re redacción dacción de normas para garantizar el a acoplamiento coplamiento de e elementos lementos construid construidos os
independientemente, garantizando la calidad de los objetos construidos y la seguridad de funcionamiento y que cumplan con: Simplificación: Se trata de reducir los modelos existentes quedándonos únicamente Simplificación: con nuestro estándar. Unificación: Para permitir la intercambiabilidad a nivel Empresarial. Especificación: Se persigue evitar errores de identificación creando un lenguaje claro y preciso.
Fecha de actualización:
19/02/14
Página:
: 4 de 18
Código o Nombre del Proyecto Software Factory
Versión 1.0 Página 5 de 18 Fecha:28/04/2014
Estándar de Base de Datos
3. Estándar de Nomencl Nomenclaturas aturas 3.1 Nombre de Base de Datos El nombre de la base de datos debe representar el propósito de la misma finalizando con el sufijo “BD”. No necesariamente debe tener el nombre del sistema al que está
asociado. Ejemplos: - InventarioBD - VentasBD - SismeBD
3.2 Tablas El nombre de las tablas deben cumplir las siguientes características: Se debe eliminar los espacios en blanco y poniendo los no nombres mbres en
nomenclatura Pascal Casing. Nota: La
Casing está compuesta por tantas palabras nomenclatura Pascal Casing
como sean necesarias. La primera letra de cada una de las palabras irá siempre en mayúsculas. Se obvia el uso de artículos. Únicamente se utili utilizarán zarán ca caractere racteress alfabéticos, salvo que por la natura naturaleza leza de dell
nombre se necesiten dígitos numéricos. Se prohíbe el uso de puntuación o símbolos. Los no nombres mbres de deben ben de especificarse en singular y completos (evitar en lo posible
abreviaturas, salvo que sea necesario por la naturaleza del nombre de la tabla). Ejemplo de nombres de tablas: -
PlanCuent PlanCuenta a (plan de cuenta)
-
Modelo (Modelo)
-
Familia (Familia)
En el caso de tablas detalle, ésta debe llamarse com como o la tabla padre, seguida de
la palabra “Detalle”.
Ejemplo de nombres de tablas detalle:
Fecha de actualización:
FacturaDetall FacturaDetalle e (Detalle de Factura) TablaMaestraDetall TablaMaestraDetalle e (Detall (Detalle e de Tabla Maestra) 19/02/14
Página:
: 5 de 18
Código o Nombre del Proyecto Software Factory
Estándar de Base de Datos
Versión 1.0 Página 6 de 18 Fecha:28/04/2014
Los nombres serán en español.
En
de que alguna tabla se relacione específicamente con otra, esta relación
caso
debe quedar expresada en el nombre y separada con un guión abajo (_). Ejemplo de nombre de tablas de relación: re lación: -
Almacen_S Almacen_Servicio ervicio (Almacé (Almacén n servicio),
-
Almacen_P Almacen_Producto roducto (Almacén producto)
Los nombres de la lass tablas deben ser entendibles y fácil de relacionar con el
objeto al que identifican. Se hará uso de esquemas, poniendo el nombre del esquema seguido de un punto
y finalmente el nombre de la tabla. Ejemplo de tablas con esquemas: -
COMPRAS.Uit
-
RRHH.Empleado
Las le letras tras a acentuadas centuadas se reemplazarán con las equivalentes no acentuadas, y en
lugar de la letra (ñ) se utilizará (ni). Ejemplo: -
AnioNacionalidad
-
Cotizacion.
3.3 Campos El nombre de los campos debe iniciar con un prefijo ((4 4 caracteres) relacionado al
nombre de la tabla al que pertenece, seguido de un guión abajo (_) y el nombre del campo. Los no nombres mbres de campos deben de especificarse en singu singular lar y con nome nomenclatura nclatura
Pascal Casing. Al igual que e en n las tabla tablas, s, los nombre nombress de campos utili utilizarán zarán car caractere acteress
alfabéticos evitando caracteres especiales. Los nombres deben ser lo más descript descriptivos ivos posible para identificar rápidamente el
dato a que hace referencia. El no nombre mbre no debe abreviarse, salvo por algún caso particul particular, ar, como por ejemplo
que el nombre sea demasiado grande. Fecha de actualización:
19/02/14
Página:
: 6 de 18
Código o Nombre del Proyecto Software Factory
Versión 1.0 Página 7 de 18 Fecha:28/04/2014
Estándar de Base de Datos
Si por alguna rrazón azón es necesario separar las palabras del nombre nombre del del campo,
deberá hacerse a través de un guión bajo (_). Los nombres deberán escribirse en español.
Ejemplos de nombre de campos: -
Prod_Codig Prod_Codigo o (Código del producto)
-
Empr_Desc Empr_Descripcion ripcion (Descripción de la empresa)
-
Vent_ Vent_TipoPago TipoPago (tipo de pago de la tabla Venta)
-
Pers_FechaNacim Pers_FechaNacimiento iento (fecha de nacimient nacimiento o de la tabla Persona)
Los campos de tipo booleano deben escribirse con una palabra que tenga un
significado verdadero o falso o en forma de pregunta. Por ejemplo no se debe usar la palabr a “estado” en un campo booleano. Ejemplos de campos booleanos booleanos:: -
Prod_Est Prod_Estado ado (incorrecto, estado=true o estado=false no me dice nada) Prod_Act Prod_Activo ivo (correcto, activo=true o activ activo=false o=false si se entiende entiende))
-
Usua_E Usua_EsAdmin sAdmin (correcto, EsAdm EsAdmin=true in=true o EsAdmin=false si tiene sentido sentido))
Para las tablas que requieran campos de auditoría se deben considerar los
siguientes
campos:
UsuarioCreacion,
UsuarioEdicion,
FechaCreacion,
FechaEdicion. Ejemplos de campos de auditoría de la tabla Venta: -
Vent_ Vent_UsuarioCreacion UsuarioCreacion (NOT NULL)
-
Vent_UsuarioEdicion
-
Vent_ Vent_FechaCreacion FechaCreacion (NOT NULL)
-
Vent_FechaEdicion
3.4 Constraints Los constraints son las limitaciones o restricciones restricciones dadas a los l os atributos o campos de una tabla. Los más comunes son: asignar a un campo o atributo la restricción de ser llave primaria, llave foránea (que proviene de otra tabla relacionada), que el campo no sea nulo, que el campo sea único, etc. a. Llave Primaria Cuando la llave primaria es un solo campo la sintaxis debe ser la siguient siguiente: e:
Fecha de actualización:
19/02/14
Página:
: 7 de 18
Código o Nombre del Proyecto Software Factory
Versión 1.0 Página 8 de 18 Fecha:28/04/2014
Estándar de Base de Datos
TipoConstraint_NombreTabla Donde:: Donde NombreTabla: Nombre de la tabla a la cual es asignado el constraint. NombreTabla: TipoConstraint:: PK (primarykey) TipoConstraint Ejemplo:: Ejemplo -
PK_Area
Cuando la llave e está stá conformada por más de un campo, la estruct estructura ura será la
misma que la anterior. b. Llave Foránea Los campos de re relación lación como la llave foránea deben de especificarse con la
siguiente sintaxis: TipoConstraint_NombreTablaDestino_NombreTablaOrigen Donde : Donde: NombreTablaDestino:: Nombre de la tabla a la cual es asignado el constraint. NombreTablaDestino NombreTablaOrigen:: Nombre de la tabla de donde proviene la llave foranea. NombreTablaOrigen TipoConstraint: FK (foreing key) TipoConstraint: Ejemplos: Ejemplos: -
PK_Provincia_Departamento
c. Índices El no nombre mbre de los índices deben tener la siguient siguiente e sintaxis:
NombreTabla_NombreCampo_ NombreTabla_Nomb reCampo_ [#] Donde: NombreTabla: Nombre tabla donde se creó el índice. NombreTabla: Nombre índice. NombreCampo: Nombre del campo de íncide creado. NombreCampo: #: Numero consecutivo de índice realizado sobre la tabla. Ejemplos: -
Venta_FechaVenta_1
-
Almacen_Stock_2
Fecha de actualización:
19/02/14
Página:
: 8 de 18
Código o Nombre del Proyecto Software Factory
Versión 1.0 Página 9 de 18 Fecha:28/04/2014
Estándar de Base de Datos
3.5 Funciones El nombre de las funciones debe tener la siguiente sintaxis: UFN_NombreFuncion Dónde: UFN:: indica que el objeto es una función. Acrónimo de “user UFN “user function”. NombreFuncion:: es el nombre de la función en Pascal Casing. NombreFuncion Ejemplos: -
UFN_CalcularImpuesto
-
UFN_DescripcionMes
3.6 Triggers El nombre de los triggers debe tener la siguiente sintaxis: TRG_NombreTabla_NNN Donde:: Donde TRG: indica que el objeto es un trigger. Acrónimo de Trigger. TRG: NombreTabla: es el nombre de la tabla donde se creó el trigger. NombreTabla: NNN: indica que tipo de trigger (INS: Insert, UPD: Update, DEL: Delete). NNN: Ejemplos: -
TRG_Compra_INS
-
TRG_Producto_DEL
3.7 Procedimientos Almacenados Para los procedimientos almacenados no se utiliza debe utilizar el prefijo “ SP”, ya que es un error puesto que "SP" significa SystemProcedure y no StoreProcedure por lo que no se debe considerar como prefijo válido. El nombre de los Procedimientos Almacenados debe tener la siguiente sintaxis: USP_NombreTabla_NNN Dónde:: Dónde USP:: indica que el objeto es un Procedimiento Almacenado. Acrónimo de “user USP stored procedure”
Fecha de actualización:
19/02/14
Página:
: 9 de 18
Código o Nombre del Proyecto Software Factory
Estándar de Base de Datos
Versión 1.0 Página 10 de 18 Fecha:28/04/2014
NombreTabla: nombre de la tabla que va a trabajar el procedimiento almacenado. almacenado. NNN: es el identificativo de la acción del procedimiento almacenado. almacenado. -
INS: indica que es una inserción. DEL: indica que es una eliminación.
-
UPD: indica que es una actualización.
-
SEL:: indica que es una selección de un registro por la llave primaria. SEL
-
LIS: indica que es una consulta de registros.
-
RPT: indica que es una consulta para un reporte.
Ejemplos:: Ejemplos -
USP_ Programacion_IN Programacion_INS S
-
USP_ Producto_SEL
-
USP_ Inventario_RPT
En los casos que el procedimiento almacenado realiza una acción específica que no necesariamente esté asociada a las operaciones básicas de una tabla se usará la sintaxis: USP_NombreProcedimientoAlmacenado Ejemplos:: Ejemplos -
USP_GenerarConsolidado
-
USP_ProcesarCostos
3.8 Vistas Los nombres de las vistas siguen las mismas convenciones que los nombres de las tablas. Se recomienda utilizar el prefijo
“VW”.
Ejemplos: Ejemplos: -
Fecha de actualización:
VW_Alumnos
19/02/14
Página:
: 10 de 18
Código o Nombre del Proyecto Software Factory
Versión 1.0 Página 11 de 18 Fecha:28/04/2014
Estándar de Base de Datos
4. Estándar de Diseño En éste apartado se van explicar las principales consideraciones para el diseño de base de datos, estructura de codificación del transact-SQL y buenas prácticas.
4.1 Collation de Base de Datos A la hora de generar generar nuestra Base de datos, vamo vamoss a elegi elegirr el siguiente collatio collation: n: SQL_Latin1_General_CP1_CI_AS Salvo que por cuestiones de diseño debamos elegir un collation diferente.
4.2 Encabezado de scripts Todos los scripts (procedimientos almacenados, funciones, etc.) deben contar con un encabezado, el cual permite conocer de manera clara de que se trata el mismo. Se deben considerar los siguientes datos en la generación de los encabeczados: -
Autor: Persona que creó el script.
-
Fecha Creación: fecha de creación del script.
-
Descripción: descripció descripción n de lo que hace el script
-
Parámetros de Entrada: En éste punto no es obligato obligatorio rio com comentar entar todos los parámetros si no parámetros que sean poco entendibles.
-
Parámetros de Salida: Detallar los parámetros de salida.
-
Modificado por: Persona que modificó el script
-
Fecha Modificación: fecha de modificación modificación..
-
Ejempl Ejemplo o de ejecución:
Ejemplo: ---------------------------------------------------------------Autor: Juan Perez -Fecha Creació Creación: n: 20/04/2013 -Descripción: Consulta de Trabajado Trabajadores res por Area ---------------------------------------------------------------- Parámetros de Entrada -@Area_Codigo @Area_Cod igo char(2): Código del área del trabajador -- Parámetros de Salida -Listado de Trabajadores ---------------------------------------------------------------- Modificado por: -- Fecha Modificación: ---------------------------------------------------------------- Ejm. ejecución: EXEC USP_Tra USP_Trabajador_L bajador_LIS_PorArea IS_PorArea '01' ---------------------------------------------------------------
Fecha de actualización:
19/02/14
Página:
: 11 de 18
Código o Nombre del Proyecto Software Factory
Versión 1.0 Página 12 de 18 Fecha:28/04/2014
Estándar de Base de Datos
4.3 Tablas y Campos
Todas las tablas creadas deben tener llave primaria, de preferencia deben ser un
número entero automático y en lo posible que dicha llave primaria esté conformada por una única columna.
Se deben definir cor correctam rectamente ente los tipos de datos que se van a a almacenar. lmacenar. Cabe
mencionar que de preferencia no se deben utilizar las columnas del tipo text o ntext, varbinary, etc. Ejemplos de tipo de datos: -
Si el dato es es una fecha, no se debe utilizar el tipo D DATETIME ATETIME sino el tipo DATE.
-
Si el dato e ess un número a año, ño, mes o día no se debe utilizar el tipo INT sino
-
el tipo SMALLINT o TINYINT. Si u una na tabla contiene u una na cantidad limitada de registros y la llave princip principal al es del tipo entero se debe utilizar el tipo SMALLINT o TINYINT según corresponda.
4.4 Variables de Tipo Tabla y Tablas Temporales Cuando se desea almacenar temporalment temporalmente e cierta cantidad de registro (de
preferencia que no excedan de los 50000) se debe utilizar una variable tipo tabla, considerando todos los estándares y buenas prácticas de una tabla normal, a excepción de la nomenclatura de los constraints. De preferencia siempre debe utilizarse una llave primaria y la cantidad de columnas de una variable tipo tabla debe ser la menor posible, considerando sólo campos clave o con tipos de datos de tamaño bien restringido. Por Ejemplo: DECLARE @TBL_CREDITOS_CAMPANIA AS TABLE DECLARE @TBL_CREDITOS_CAMPANIA TABLE ( ( NRO_CREDITO INT NOT NULL, COD_CLIENTE VARCHAR(15) NOT NULL, MONTO DECIMAL(16,2) NOT NULL, PRIMARY KEY (NRO_CREDITO) );
Asimismo pue puede de ha hacer cer uso de dell coma comando ndo WITH para la creaci creación ón de tablas en memoria. Recuerde que siempre antes de iniciar el comando WITH debe existir
Fecha de actualización:
19/02/14
Página:
: 12 de 18
Código o Nombre del Proyecto Software Factory
Versión 1.0 Página 13 de 18 Fecha:28/04/2014
Estándar de Base de Datos
un punto y coma (;) delante de este, adicionalmente solo es permitido un comando WITH por consulta o procedimiento.
Por ejemplo: WITH TBL_CREDITOS_CAMPANIA ;WITH TBL_CREDITOS_CAMPANIA AS ( AS ( SELECT NRO_CREDIT SELECT NRO_CREDITO, O, COD_CLIENTE, MONTO FROM PR.PR_CREDITOS FROM PR.PR_CREDITOS (NOLOCK) WHERE COD_CAMPANIA = ‘001’ WHERE AND IND_ESTADO = ‘A’
) SELECT NRO_CREDIT SELECT NRO_CREDITO, O, COD_CLIENTE, MONTO FROM TBL_CREDIT FROM TBL_CREDITOS_CAMPANIA OS_CAMPANIA Cuando se desea almacenar temporalmente una cantid cantidad ad elevada de re registros gistros
(mayor a 50000) se debe utilizar una tabla temporal la cual debe empezar con el prefijo # o ## según el ámbito, asumiendo todas las propiedades y requerimientos de una tabla normal, a excepción de la nomenclatura de los constraints. Estas tablas siempre estarán almacenadas en la base de datos TEMPDB. Por ejemplo: CREATE TAB T ABLE LE ##TBL_CREDITOS_CAMPANIA ##TBL_CREDITOS_CAMPANIA ( NRO_CREDITO DECIMAL(10) NOT NULL, COD_CLIENTE VARCHAR(15) NOT NULL, MONTO DECIMAL(16,2) NOT NULL, PRIMARY KEY (NRO_CREDITO) ); ó SELECT NRO_CREDIT SELECT NRO_CREDITO, O, COD_CLIENTE, MONTO INTO ##TBL_CREDITOS_CAMPANIA INTO FROM PR.PR_CREDIT FROM PR.PR_CREDITOS OS (NOLOCK) WHERE COD_CAMPANIA = ‘001’ WHERE AND IND_ESTADO = ‘A’
Todas las tablas temporales deben ser limpiadas o elimin eliminadas adas antes de su
creación, para esto utilizar el siguiente comando previamente a la creación de la tabla temporal.
Fecha de actualización:
19/02/14
Página:
: 13 de 18
Código o Nombre del Proyecto Software Factory
Versión 1.0 Página 14 de 18 Fecha:28/04/2014
Estándar de Base de Datos
Por ejemplo: IF OBJECT_ID(‘TEMPDB..##TABLA_TEMPORAL’) IS NOT NULL DROP TABLE ##TABLA_TEMPORAL’
4.5 Procedimientos Almacenados Los Procedimientos Almacenados, Funciones definidas por el usuario y
Disparadores (triggers) siempre deben empezar con la cláusula BEGIN y terminar con la cláusula END. Por ejemplo: CREATE PROCEDURE [[Nombre Nombre_Procedimiento] _Procedimiento] ( [Nombre_Parametro] [Nombre_Parametro] [TIPO_DATO] [, …] )
AS BEGIN (Instrucciones T-SQL) …
END GO Las clausulas SET NOCOUNT ON y SET NOCOUNT OFF deben ir establecidas
dentro del procedimiento al inicio y final respectivamente, dentro de las clausulas BEGIN y END, a fin de eliminar la notificación del Nro. de registros afectados por cada sentencia T-SQL lo cual elimina un tráfico innecesario de confirmación del procedimiento. Por Ejemplo: CREATE PROCEDURE [Nombre_Procedimiento] ( [Nombre_Parametro] [Nombre_Parametro] [TIPO_DATO] [, …] )
AS BEGIN
SET NOCOUNT ON (Instrucciones T-SQL) …
SET NOCOUNT OFF END El nombre de lo loss parámetros deben ser iguales a all nombre de lo loss campos de las
tablas que va a manipular. Por ejemplo: Se tiene la siguiente tabla: Fecha de actualización:
19/02/14
Página:
: 14 de 18
Código o Nombre del Proyecto Software Factory
Estándar de Base de Datos
Versión 1.0 Página 15 de 18 Fecha:28/04/2014
CREATE TABLE Persona ( Pers_Codigo int, Pers_Nombre varchar(100), Pers_Activo bit ) El procedimiento almacenado de inserción sería el siguiente: CREATE PROCEDURE USP_Persona_INS @Pers_Codigo int, @Pers_Codigo int, @Pers_Nombre varchar(100), @Pers_Nombre varchar(100), @Pers_Activo bit @Pers_Activo bit AS BEGIN SET NOCOUNT ON; INSERT INTO Persona( Pers_Codigo, Pers_Nombre, Pers_Activo ) ALUES ( VALUES V @Pers_Codigo, @Pers_Nombre, @Pers_Activo ) SET NOCOUNT OFF; END
4.6 Generación de Consultas Para la escritura de código SQL utilizar mayúsculas para las sentencia sentenciass o
palabras reservadas propias del SQL Por ejemplo: SELECTCli_Codigo, Cli_Nombre , Cli_ApellidoPaterno, Cli_ApellidoMaterno, Cli_Edad FROM CLIENTE (NOLOCK) ORDER BY Cli_ApellidoPaterno Utilizar el Tabulador para separar los campos de una condición indentando el
código para que sea siempre claro. Todas las consultas deben contener el hint (NOLOCK) a un lado del nombre de la
tabla que se está consultando. A excepción de cuando las circunstancias ameriten lo contrario. Fecha de actualización:
19/02/14
Página:
: 15 de 18
Código o Nombre del Proyecto Software Factory
Versión 1.0 Página 16 de 18 Fecha:28/04/2014
Estándar de Base de Datos
La declaración de variables dentro de un procedimient procedimiento, o, función o disparador
debe ser consecutiva y se debe separar las variables por comas. Por ejemplo: DECLARE DECLARE
@LCH_COD_SU @LCH_COD_SUARIO ARIO VARCHAR(15) VARCHAR(15),, @LDC_TIPO_CAMBIO DECIMAL(16,8), @LI_NRO_CUOTAS INT, ...
Para la asignación de masiva de datos a variables dentro de un procedi procedimiento miento o
función se debe utilizar la instrucción SELECT y se debe separar cada asignación por comas de variables. Caso contrario cuando sea una asignación única puede utilizar el comando SET. Por ejemplo: SELECT SELECT
@LCH_COD_S @LCH_COD_SUARIO UARIO = 'EDIE 'EDIEZ', Z', @LDC_TIPO_CAMBIO = 25.0001, @LI_NRO_CUOTAS = 10, …
Nunca se deben utiliz utilizar ar funciones dentro de la cláusula WHERE relacionados a
una columna debido a que afecta a los índices asociados a la tabla y disminuye el rendimiento de la consulta. Por ejemplo: Mala práctica SELECT Cli_Codigo, Cli_Nombre , Cli_ApellidoPaterno, Cli_ApellidoMaterno FROM CLIENTE (NOLOCK) WHERE YEAR(Cli_FechaRegistro) = 2013 La consulta correcta sería: SELECT Cli_Codigo, Cli_Nombre , Cli_ApellidoPaterno, Cli_ApellidoMaterno, FROM CLIENTE (NOLOCK) WHERE Cli_FechaRegistro BETWEEN ‘01/01/2013’ AND ‘31/12/2013’ Nunca deben utilizarse subconsultas correlacionadas para extraer un vvalor alor de
otra tabla, dado que esto tiene el mismo impacto de utilizar una función de usuario dentro de la consulta.
Fecha de actualización:
19/02/14
Página:
: 16 de 18
Código o Nombre del Proyecto Software Factory
Estándar de Base de Datos
Versión 1.0 Página 17 de 18 Fecha:28/04/2014
Por ejemplo: Mala práctica SELECTNro_Credito Cod_cliente, Nombre = (SELECT nombre FROM CLIENTE WHERE Cod_cliente = CREDITO.Cod_Cliente), CREDITO.Cod_Cliente) , Direccion_Casa = (SELECT direccion FROM DIRECCION_CLIENTE WHERE Cod_cliente = CREDITO.Cod CREDITO.Cod_Cliente _Cliente)) AND TipoDireccion TipoDireccion = ‘C’
FROM CREDITO (NOLOCK) La consulta correcta sería:
SELECT A.Nro_Credito A.Nro_Cre dito A.Cod_cliente, A.Cod_clien te, B.Nombre, C.Direccion FROM CREDITO A (NOLOCK) INNER JOIN CLIENTE B (NOLOCK) ON A.cod_cliente ON A.cod_cliente = B.cod_cliente B.cod_cliente INNER JOIN DIRECCION_CLIENTE C (NOLOCK) ON A.cod_cliente ON A.cod_cliente = C.cod_cliente C.cod_cliente AND ‘C’ = C.TipoDireccion Cuando se desee consultar más de una ta tabla bla si siempre empre se de deben ben utiliza utilizarr alias para
facilitar la escritura de consulta. Todas las columnas deben tener el alias respectivo. No se debe utilizar el hint TOP y menos en subconsult subconsultas as correla correlacionadas, cionadas, en vez
de TOP utilice ROW_NUMBER, RANK, DENSE_RANK.
Fecha de actualización:
19/02/14
Página:
: 17 de 18
Código o Nombre del Proyecto Software Factory
Responsable/Cargo
Fecha de actualización:
19/02/14
Estándar de Base de Datos
Firma
Versión 1.0 Página 18 de 18 Fecha:28/04/2014
Fecha
Página:
: 18 de 18
View more...
Comments
