Menu

Mejores prácticas SQL Server – Nombrado de objetos

Julio 31, 2011 - SQL Server

Introducción

En el mundo del desarrollo de habla mucho acerca de buenas prácticas, patrones de diseño y una cantidad de vocabulario como patrones, diseños, etc. Y aunque el desarrollo a nivel de base de datos en muchos casos no exige una arquitectura es importante tener en cuenta ciertos parámetros a la hora de crear procedimientos almacenados.

Las bases de datos si lo pensamos con detenimiento son el corazón de la aplicación en muchos sentidos, y por tanto es extremadamente importante para DBA’a y DBD’s crear objetos que tengan siempre un óptimo desempeño para evitar cuellos de botella en la aplicación. He aquí algunas prácticas que he recopilado, algunas por la red otras por experiencia:

Estándar en los nombres

Se debe tener un estándar para nombrar los objetos, no solo a nivel de base de datos sino también a nivel de instancia, esto es, que los nombres de las propias bases de datos deben seguir normas específicas que sugieran a simple vista su aplicación. Veamos algunos estándares para los objetos de la base de datos:

Base de datos

Como objeto en la instancia debe tener su propio estándar de codificación, por ejemplo, en algunas organizaciones utilizar como nombre de base de datos el nombre del aplicativo que la usa, por ejemplo: RegistroClientes, Facturacion, etc. Así es fácilmente identificable.

Tablas

Las tablas representan una instancia de una entidad, y DEBE contener solo información que corresponde a la entidad que representa (No vamos a guardar la dirección del cliente en la tabla proveedor)  así pues el nombre de ésta debe ser alusivo a la información que contiene, por ejemplo: Proveedores, Clientes. Es a consideración del DBA o del DBD decidir si se usaran plurales o singulares para nombrar las tablas así también como las tablas que contienen información de más de una entidad, por ejemplo: PedidosCliente, también puede llamarse: PedidosPorCliente, lo importante es que sea claro y solo con verla podemos saber qué entidad representa y por ende la información que contiene.

Consideraciones

Prefijos como: tblClientes no aportan nada al nombre.

Si tenemos alguna especie de lógica especial o compleja y necesitamos ver agrupados un grupo de tablas (En el SQL Server Managment, al expandir las tablas) podemos usar prefijos indicando el “grupo” al cual pertenece, ejemplo: Tenemos dos tablas que pueden tener el mismo nombre, pero pertenecen a distintos procesos podemos hacer lo siguiente: RH_Cliente y V_Cliente, pertenecientes a Recursos humanos y ventas, o mejor aún la solución para esto es usar esquemas.

Vistas

Las vistas no son más que tablas filtradas, por lo tanto la información que presentan está definida en su ámbito y límites, lo cual nos ayuda a nombrarlas. Por lo que nombrar las vistas en mi opinión debe ser en función de la consulta más que en las entidades, por ejemplo: ResumenVentas2011, ClientesFrecuentes, son perfectamente entendibles.

Consideraciones

Nombrar vistas en base a las tablas que consulta también puede ser útil pero no siempre funcional, por ejemplo: si en una vista combinamos Clientes y Direcciones la vista se llamaría DireccionesClientes, pero si existe ya una tabla con ese nombre?.

Procedimientos almacenados

Los procedimientos almacenados siempre tiene una tarea específica y en base a éste los debemos nombrar, por ejemplo: ObtenerDetalleClientes, sin embargo personalmente no me gusta esta aproximación ya que a nivel visual (En SQL Server Managment Studio al expandir Procedimientos almacenados) estarán juntos todos los que comienzan por “obtiene” lo cual no tiene mucho sentido, prefiero que el SP comience por el nombre de la entidad a la que está afectando, por ejemplo: ClientesObtenerDetalle, asi en el Managment estarán todos juntos los procedimientos de Clientes.

Si el procedimiento afecta más de una tabla no debe afectar su nombre, es decir debe ir en función de el proceso, por ejemplo: FacturaInsertar seguramente ingresa su encabezado y detalle y si los tenemos separados pues deberían ser: FaturaEncabezadoInsertar y FaturaDetalleInsertar.

Consideraciones

NUNCA colocar como prefijo a los procedimientos “sp_”, ésta es una práctica bastante difundida que no está para nada bien, (a menos que sea un procedimiento que se guarde en la BD master), la razón es que SQL Server coloca este prefijo a los procedimientos del sistema (No te habías dado cuenta?), por tanto si le dices que ejecute un procedimiento con prefijo SP, primero lo buscara en master.

Funciones de usuario

En cierto sentido una función de usuario es un procedimiento almacenado, claro que con ciertas características, debemos nombrar el UDF de acuerdo a su funcionalidad, como éstos no van dirigidos a una tabla en específica pueden nombrarse de acuerdo a lo que hacen, por ejemplo: CalcularDigitoVerificacion.

Triggers

Los triggers también son un tipo especial de procedimiento almacenado, para nombrarlo sugiero tener en cuenta que: un trigger no puede existir por sí solo, es decir, debe estar asociado a una tabla, por tanto tiene mucho sentido colocar en el nombre la tabla a la cual pertenece. Ademas de esto los triggers también están asociados a una operación sobre la tabla (SELECT, DELETE, UPDATE, INSERT), asi que también tiene sentido colocar esta información en el nombre, por ejemplo: ClientesInsertTrigger.

Índices

En este apartado en lo que a mí respecta, prefiero dejar que sea el SSMS quien me sugiera el nombre, sin embargo, como regla general podemos tener en cuenta lo siguiente: el nombre del índice debe comenzar con un prefijo que indique el tipo de índice, nombre de la tabla en donde se creara, columna y si lo desean información adicional, por ejemplo: PK_Clientes_ClienteID_ASC.

En el caso especial de las foráneas que referencian dos tablas podemos usar la siguiente norma: FK_+TablaQueReferencia+ColumnaQueReferencia_+TablaReferenciada+ColumnaReferenciada.

Columnas

Realmente en este apartado lo que hay que decir es que debemos nombrar las columnas con sentido común y de acuerdo con la información que se está guardando, ya es decisión de uds. Si por ejemplo a la columna ID de la tabla clientes le colocan: ClienteID o ID, Si se usa la primera forma, todos los nombres de columnas de la tabla deben ser precedidos por el mismo, es decir, en la tabla clientes: ClienteID, ClienteNombre, ClienteDireccion. ¿Por qué? Así cuando se esté en una consulta compleja, como por ejemplo con un JOIN no habrá conflicto de ambigüedad con nombres.

Tipos de datos definidos por el usuario

Realmente son columnas con tipo de datos ‘especiales’ por así decirlo, por tanto creo que usando el estándar de columnas estará bien.

Consideraciones adicionales

Happy coding!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *