¡Hola a todos!
Este tema me interesa porque soy un partidario de la estandarización de nomenclaturas. Personalmente he comprobado cómo el llevar un estándar reduce significativamente los tiempos de desarrollo, depuración, mantenimiento y modificación del software.
En lo referente a bases de datos, de entrada les comento que no uso el guión bajo ("_") en el nombre de sus elementos. No lo utilizo para los nombres de tablas, campos y otros objetos por tres razones:
1. Es
difícil de teclear. Esa fracción de segundo que dedicamos a sostener el Shift mientras presionamos (y recordamos su posición según la configuración de teclado) el guión bajo termina siendo un detalle incómodo para el programador. Y todos sabemos que en desarrollo de software entre menos
detalles incómodos tengamos mejor y más rápido salen las cosas. Somos muy dados a optimizar la memoria y tiempo consumidos por las rutinas de código, pues lo mismo debemos aplicar a las rutinas laborales ¿no creen?
.
2. Es poco estético y muchas veces innecesario. Cuando se permite el uso de mayúsculas y minúsculas (y no hay conflictos técnicos importantes al respecto), se puede prescindir del guión bajo empleando altas y bajas a la manera de
NomenclaturasBuenas,
PrecioMenudeo,
PrecioMayoreo.
3. Se hace invisible en hipervínculos y textos subrayados. Si por ejemplo, en la documentación de la base de datos tenemos una sección o hipervínculo con el título subrayado "
DEPENDENCIAS DE LA TABLA AREAS_VIGENTES" ("DEPENDENCIAS DE LA TABLA AREAS_VIGENTES"), un programador de nuevo ingreso podría pensar que se trata de las dependencias vigentes de la tabla AREAS en lugar de las dependencias de la tabla AREAS_VIGENTES. Ese tipo de confusiones entorpecen el trabajo de los desarrolladores.
Por otra parte, creo cada tabla con un nombre en plural cuando ésta podrá contener más de un registro, como sucede casi siempre (por ejemplo, EMPLEADOS, AREASVIGENTES), y en singular solamente cuando es una tabla de un sólo registro (por ejemplo, CONFIGURACION, DATOSEMPRESA).
Con respecto al campo de llave primaria o de
identidad, éste lo nombro simplemente "ID" (el uso del término
ID es ya un estándar fuertemente aplicado y aceptado por la comunidad mundial de desarrolladores), y para los campos que se relacionan con el
ID de otra tabla utilizo el nombre completo de esa otra tabla con el prefijo "ID". Por ejemplo, si tenemos dos tablas, "VENTAS" Y "VENTASPARTIDAS", en una relación maestro-detalle, respectivamente. Los campos llave de dichas tablas son:
VENTAS.ID (identificador de registro, llave primaria)
VENTASPARTIDAS.ID (identificador de registro, llave primaria)
VENTASPARTIDAS.IDVENTAS (relacionado con VENTAS.ID, llave externa).
Nótese también que el nombre de la tabla detalle, "VENTASPARTIDAS", lleva como prefijo el nombre de la tabla maestra ("VENTAS").
Hay quienes no utilizan nunca
ID como nombre completo de campo, sino que siempre le anexan el nombre de una tabla ("VENTAS.IDVENTAS", por ejemplo). Encuentro tres desventajas en esa forma de hacerlo:
1. Si el nombre de la tabla cambiara, tendríamos que cambiar también el nombre del campo.
2. Es un pleonasmo. Como decir «cayó algo del cielo de arriba». ¡Cervantes se levantaría de su tumba! Ya sabemos que el cielo está arriba. En programación debe uno cuidar que no se caiga ni en la escasez ni en la abundancia de texto, ya que los dos extremos le exigen una mayor cantidad de tiempo-neurona al cerebro.
3. Se pierde la distinción entre los nombres de campos de llave primaria y los de llave externa/secundaria. Como lo propongo ("VENTAS.ID"), al comenzar a leer la sentencia SQL «Select IDVentas...» podemos intuir que se trata de una consulta sobre la tabla VENTASPARTIDAS antes de llegar al
From. En cambio, si el campo fuera "VENTAS.IDVENTAS", forzosamente tendríamos que leer algo más de la sentencia Select para estar seguros de si es una consulta sobre la tabla VENTASPARTIDAS o sobre la tabla VENTAS.
Allende, hay quienes, para campos relacionados, utilizan el nombre de la otra tabla con el par de letras "ID" como sufijo en lugar de prefijo. Ejemplo: "VENTAS.CLIENTESID". El problema de ese estilo es que se pierde uniformidad y eficacia cuando listamos o buscamos los campos de una tabla por orden alfabético. Por ejemplo, quizá estamos tecleando instrucciones de la aplicación o SQL en un editor que soporta auto completado de código (
code insight), y enseguida queremos escribir el nombre de un campo relacionado pero no recordamos como se llama la otra tabla. De la manera que lo propongo ("ID" como prefijo), sólo tenemos que teclear ID y estaremos a un paso de seleccionar el campo cuyo nombre completo no recordábamos. En cambio, si se utiliza ID como sufijo, tenemos que examinar la lista de campos completa para localizar el nombre que buscamos.
Este esquema de nomenclaturas que propongo y utilizo ha resultado de lo más eficiente e inteligible para los desarrolladores que trabajamos en diversos proyectos de mi empresa y de algunos clientes. La esencia del mismo es
ser prácticos y sencillos, no complicarnos con nomenclaturas bárbaras sostenidas más en fundamentalismos sico-informáticos que en su facilidad de uso y resultados de la vida real.
Generalmente el programador común no acepta con facilidad cambiar de estilo (alguna vez yo fui uno de tantos obstinados, viviendo en mi pequeño y
perfecto mundo). No obstante, la tolerancia y la flexibilidad son un signo de madurez muy valorado por las empresas, y dos cualidades imprescindibles para lograr lo que uno quiere en la vida.
Propongo mi esquema de nomenclaturas para bases de datos, como cimiento de un estándar al que podamos contribuir todos.
Espero esto sea de utilidad, seguimos en contacto.
Ahora si, a dormir se ha dicho. ¡Hasta mañana!
Al González.
