Introducción
Cuando uno empieza a diseñar una base de datos, debemos decidir como es que vamos a llamar a nuestras tablas, vistas, funciones, procedimientos, columnas, claves primarias y foráneas, etc. Tu aplicarás estas reglas mientras nombras cualquier cosa dentro de la base de datos.
Usar una convención de nombres no es la regla, pero es deseado. Mientras la mayor parte de las reglas son lógicas (y normalmente tenemos algo de lógica para trabajar en estas cosas), algunas no lo son del todo.
Ahora ¿porqué utilizar una convención de nombres?
Una consecuencia de utilizar una nomenclatura de nombres, es que simplifica el trabajo y por lo tanto tu vida. Una base de datos de una aplicación real normalmente tiene muchas tablas. En muchas ocasiones cientos de tablas y si no eres desordenado esas tablas siguen algunas reglas de organización. Y una de esas reglas es tener una nomenclatura establecida. Eso incrementará la legibilidad de la base de datos y pasarás menos tiempo buscando lo que necesitas. Y eso hará que consultar la base de datos INFORMATION_SCHEMA en busca de patrones especÃficos, por ejemplo comprobando si todas las tablas tengan el nombre de la clave primaria que empiece con "id"; o si tenemos un procedimiento almacenado que ejecuta un INSERT para cada tabla, etc.
¿No es suficiente? Hay otra buena razón. La base de datos vivirá por mucho tiempo. Y los cambios en la base de datos son usualmente evitados y solo son realizados cuando son verdaderamente necesarios. ¿Porqué? Debido a que cambiar el nombre de una tabla puede afectar a muchos lugares en tu código. Y al contrario de la base de datos el código de tu aplicación puede cambiar muchas veces. Incluso el lenguaje en que fue programada la aplicación. Por lo que puedes esperar la base de datos no cambiará mucho de su versión inicial de producción. Por eso empezar de la forma correcta, con el sistema de nomenclatura establecido ayudará a un trabajo más sencillo.
Una razón más es que no serás el único que trabajará en ella. Si es legible cualquiera que llegue a trabajar con ella, sabrá qué encontrar y cómo encontrarlo y cómo los datos están relacionados. Esto sucede especialmente en el caso en que se estén utilizando las reglas de nomenclatura más comunes. En caso que tengas algo especÃfico, se puede especificar en un breve documento.
¿Cómo nombrar a las tablas?
Primera sugerencia: utilizar letras minúsculas cuando se nombren objectos de base de datos. Para dos o más palabras, debe utilizarse un guión bajo.
Cuando se "bauticen" tablas, hay dos opciones: utilizar el singular o el plural. La sugerencia más común es utilizar el singular.
Si se están nombrando entidades que representan hechos del asunto real, deberÃas utilizar sustantivos (marca, clase, producto, paÃs, etc.). En lo posible que sea una sola palabra que describa lo que contiene la tabla.
Segunda sugerencia: utilizar el singular para el nombre de tablas y no el plural, el plural puede llevar a bautizar de forma rara a algunas tablas (en vez de venta_cliente se convertirá en ventas_clientes).
En ocasiones no hay forma de evitar crear una tabla cuyo nombre tenga dos o más palabras.
Para relaciones entre dos tablas, se debe utilizar los nombres de las dos tablas y puede ser necesario agregar un verbo entre los nombres para describir cuál es la acción.
Imagina que tenemos las tablas usuario y rol. La relación entre ambas es de muchos a muchos, ya que un usuario puede tener muchos roles y un rol puede tenerlo muchos usuarios. La relación puede llamarse usuario_rol.
Siempre hay excepciones si son lógicas. Tener tablas producto y factura podrÃa llevar a tener una tabla factura_producto pero es mejor factura_item o factura_detalle, lo cual es más conocido en el mundo real.
¿Cómo llamar a las columnas o campos?
Depende del tipo de columna o campo:
1. Si es una clave primaria: lo más común es que un sólo campo sea la clave primaria. PodrÃa ser útil llamarla de forma simple, por ejemplo producto_id o producto_pk.
2. Si es una clave foránea: ya que las claves foráneas son las claves primarias de otras tablas, debe mantenerse el mismo estilo de nombramiento. Puede ser producto_id.
3. Si es un campo de datos: son atributos donde almacenamos datos del mundo real. Las mismas reglas son aplicadas cuando se nombran a las tablas. Hay que utilizar la menor cantidad de palabras para describir lo que está almacenado en esa columna, por ejemplo pais_nombre o pais_codigo. Si es posible que dos o más tablas tengan una columna con el mismo nombre, hay que agregarle algo para que el nombre sea único. No necesariamente esto último es obligatorio, pero ayuda mucho cuando empÃezas a construir consultas y no deseas confundir sobre a que tabla pertenece cada columna.
4. Si es una campo de fecha: en este caso es bueno describir lo que la fecha representa. Por ejemplo fecha_inicial o fecha_final son buenas descripciones. Si tu quieres, puedes hacerlo más descriptivo, como producto_fecha_vencimiento.
5. Si es un flag o campo bandera: estos campos indican si una acción tomó lugar o no, puede ser es_activo o es_enviado.
Convenciones de nombre para procedimientos funciones y vistas
Procedimientos almacenados: usualmente se ejecuta una conjunto de acciones y retornar un conjunto de datos. Por ejemplo, un nombre podrÃa ser cliente_insertar. Representa la acción a realizar.
Funciones: éstas realizar cálculos simples y retornan valores. Al igual que los procedimientos hay que nombrarlos de igual forma, describiendo lo que la función hace. Por ejemplo f_calcular_inventario.
Vistas: seguimos el ejemplo que son aplicados a procedimientos almacenados. Las vistas que prefiero son las del ocaso o el amanecer. Perdón por el mal chiste. No utilizo vistas, pero para identificar se recomienda poner una "v" adelante del nombre. Por ejemplo "v_productos_vencidos".
Conclusión
Utilizar una nomenclatura especifica es algo muy útil. aplicar unas reglas especificas no sólo ayudará a facilitar tu labor, sino la de los demás que trabajen en la base de datos.
0 Comentarios