Introducción
Un DBMS no facilita diseñar correctamente una base de datos. Muchas veces debemos haber pasado por lo mismo. Nos piden diseñar la base de datos para un sistema, entonces procedemos a crear tablas y nombrarlas del modo que se nos ocurra o entendamos, pero cuando empezamos a desarrollar reportes para el sistema, puede ser dificultoso.
¿Haces eso? Pues ¡¡para!!. Recuerda que es un trabajo, y es un reflejo de tí como empleado y habla también acerca de tí como persona. Claro que a veces toma tiempo extra para entender el modelo de datos, pero ese tiempo extra pagará dividendos cuando necesites extraer datos o permitir el acceso a ellos de los usuarios.
Veamos cual sería una buena forma de llamar a nuestras bases de datos, tablas, columnas, procedimientos almacenados e incluso vistas.
Convenciones para tablas o vistas
| Tipo de Tabla o Vista | Sufijo para Tabla | Descripción |
| Tabla de Históricos | hist | Esta tabla almacena información histórica. Típicamente es una relación de una a varios. |
Tabla de Referencia
| ref | Este tipo de tabla almacena nombres y descripciones. Ej. 1=Perros. |
| Snapshot | current | Almacena información actualizada, típicamente se utiliza con tablas históricas para almacenar el último registro para una clave externa. |
| Primera Instancia | orig
| Almacena la primera instancia de una clave externa, es lo opuesto al Snapshot, pero contiene los mismo datos si es que sólo hay un registro de la clave externa. |
Casos especiales de Vistas
Muchos DBA no dejan que los usuarios accedan directamente a las tablas, para eso utilizan vistas para las consultas contra las tablas. Es una buena práctica siempre que no haya demasiados joins.
Para una vista, podemos nombrarla con una letra "v" o "vw" al comienzo del nombre, que ayuda cuando cuando se lista las vistas fuera del Administrador Corporativo tal como Microsoft Access. Gracias a ese prefijo el usuario puede distinguir si es una vista o una tabla, y cual es el tipo de información almacenada en la tabla y que tipo de tabla es.
Notarán que no se indica utilizar un prefijo para una tabla. Esto es para establecer que siempre que un objeto no tenga prefijo es una tabla, y cuando tenga prefijo es una vista o procedimiento almacenado.
Convenciones para nombrar columnas
A veces uno tiene reglas para nombrar tablas, vistas o procedimientos almacenados. Sin embargo cuando se trata de columnas no lo tenemos. Una regla que puede ayudarnos mucho y ahorrarnos tiempo es llamar a la columna A de la tabla 1, llamarla también A en la tabla 2. Un simple movimiento que puede salvarnos de muchos problemas.
Tipo de Columna |
Sufijo de Columna |
Descripción |
Nombre del elemento |
name |
Usada para describir el nombre de una clave principal |
Descripción del elemento |
desc |
Usada para describir el nombre con más detalle |
Fecha de los datos |
entry_date |
Usada para marcar con fecha una fila |
Usuario que ingresó datos |
ingresado_por |
Usada para registrar que usuario o aplicación introdujo los datos |
Fecha de actualización de los datos |
update_date |
Muestra la fecha en que se actualizaron los datos |
Usuario que actualizó los datos |
modificado_por |
Utilizada para almacenar el usuario que modificó los datos |
Clave primaria númerica |
<<>>_id |
Utilizada describir la clave primaria cuando la clave es un valor númerico |
Procedimientos Almacenados
Una convenció que puede utilizarse es 'usr_<
>, de modo que cuando se depure la aplicación se sabe que un objeto con 'usr_' es un procedimiento almacenado. Hay que incluir dentro del nombre algo que indique que es lo que hace el procedimiento almacenado. Por ejemplo si un procedimiento almacenado actualiza la categoría de un producto, se le puede llamar 'usr_ActualizarCategoria'.
Bases de Datos
Ultimamente el uso de una convención para llama a la base de datos. Similar a la convención de nombres para procedimientos almacenados, como usar el prefijo 'dev' y 'prod' para distinguir entre una base de datos de desarrollo y una de producción.
Conclusión
Las convenciones de nombres que menciono no son dificiles de seguir. Usualmente, bueno, casi siempre somos presionados en el tiempo para diseñar una base de datos. No hay que sentirse mal por eso, no es nuestra culpa. Pero hay que tomarnos el tiempo para establecer y seguir nuestras convenciones de nombres. Tres meses después, cuando revisemos el código nos agradeceremos a nosotros mismos por eso. La clave de todo esto es ser consistente. Si somos consistentes, modificar el código será mucho más fácil.
¿Ustedes tienen alguna convención de nombres?
