Una de las cosas más importantes que tiene que hacerse para garantizar que los programas resulten fáciles de desarrollar y posteriormente darles mantenimiento es utilizar estándares de nomenclatura. El problema es que esta práctica sólo se suele asociar al nombre de los ficheros y al estilo del código fuente, pero hay otras áreas en las que también resultan de crucial importancia. Hoy me estaba fijando en los nombres de los objetos en Base de Datos, como las tablas por ejemplo.

Es bastante frecuente, sobre todo en aplicaciones web sencillas, tener tablas con nombres comunes como CLIENTES o FACTURAS. Esto resulta claro y conciso durante el diseño y desarrollo, pero a la larga puede traer problemas. Por ejemplo, no se pueden instalar dos aplicaciones distintas en una misma instancia de Base de Datos para un mismo usuario si los nombres de las tablas que utilizan son iguales, y usando nombres tan comunes es bastante normal que antes o después se den conflictos. Pero sobre todo resulta problemático cuando se tiene que dar mantenimiento a la aplicación y se tiene que medir de forma rápida el impacto de una modificación importante sobre una tabla bastante utilizada como puede ser CLIENTES. En la mayoría de los casos lo que se hace es buscar la palabra «CLIENTES» en todos los fuentes, y ocurre que aparece en comentarios, nombres de variables, nombres de funciones, cadenas de texto, sentencias SQL, etc. siendo difícil discriminar de forma rápida las modificaciones concretas que habrá que realizar.

Una mejor estrategia de nomenclatura es prefijar los nombres de los objetos con unas siglas identificativas del proyecto. Por ejemplo, si se está elaborando el sistema SuperGes 1.0, basta con anteponer al nombre de las tablas un prefijo tal como «SGE_», pasando entonces las tablas a llamarse «SGE_CLIENTES» o «SGE_FACTURAS».

Este simple método anula completamente la probabilidad de conflicto de nombres con los distintos proyectos que desarrollemos dentro de nuestra empresa, pero no anula la probabilidad de conflicto con aplicaciones de otras empresas que pueden estar siguiendo nuestro mismo método de nomenclatura. Una solución más completa, utilizada en algunos paquetes de software libre, es decidir el prefijo de las tablas en el momento que se realiza la instalación de la aplicación.

Drupal por ejemplo permite que los nombres de las tablas se prefijen como se quiera al crear la Base de Datos durante el proceso de instalación, y que se ponga en un fichero de configuración el prefijo escogido. Esto resulta especialmente útil cuando se tienen varias versiones instaladas a un mismo tiempo, ya que nos permite tener varios conjuntos de unas mismas tablas pero prefijadas de forma distinta para evitar conflictos, como «drp468_» y «drp472_» por ejemplo.

La magia del asunto consiste en que dentro del código fuente de Drupal los nombres de las tablas en las sentencias SQL se escriben encerradas por llaves, como en «SELECT nid FROM {node}». De esta forma la capa de acceso a Base de Datos puede detectar la referencia a cada tabla y anteponerle el prefijo escogido. Si el sobrecoste que implica sustituir en tiempo de ejecución una cadena de texto por otra resulta prohibitiva, cosa que dudo ya que en comparación el tiempo de acceso a Base de Datos será siempre de varios órdenes de magnitud mayor, se puede optar por sustituir los nombres de las tablas dentro de los propios ficheros fuentes durante el proceso de instalación del software, algo plausible si se utiliza algún lenguaje como PHP por ejemplo, que normalmente es interpretado.

Hablando de Base de datos, otra práctica bastante común en algunos desarrollos web sencillos es el obviar el uso de foreign keys. A veces simplemente porque no hay más remedio, por ejemplo porque el gestor de Base de Datos que se está utilizando no lo permite, pero la mayoría de las veces es por pura dejadez y una cierta aversión al uso de las mismas. No sé, es como si tuvieran mala fama o se pensase que resultan totalmente inútiles. Las excusas hablan de que ralentizan el funcionamiento, que dificultan los imports parciales, y que en general no sirven para nada cuando las relaciones son evidentes. Todas excusas vanas. Lo único cierto y verdad es que sólo implican una carga extra para el servidor cuando se insertan o borran registros, no cuando se hacen consultas, que es lo que hace el 99% del tiempo una aplicación web típica. Tampoco dificultan los imports, todo lo contrario, ayudan a que no quede información incoherente en Base de Datos que de otra forma podría ser difícil de depurar. Y por supuesto sí sirven para algo, sobre todo cuando tenemos que enfrentarnos a modelos que constan de 300 o 400 tablas, y no las 6 ó 7 de una aplicación pequeña y que hemos desarrollado completamente nosotros. Obtener la estructura puede ser sencillo, pero averiguar el uso y la intención es normalmente una labor más compleja, por lo que toda ayuda resulta poca.