Estándar de nomenclatura en BDD

Hoy una entrada sobre el sistema personal de nomenclatura de BDD que me gusta utilizar en mis aplicaciones cuando tengo la capacidad de decidir. No siempre es así, a veces se trabaja con BDD heredadas o uno no es el responsable de esa área, pero cuando es posible, personalmente prefiero utilizar este sistema que me proporciona la sensación de tener más "ordenada" la BDD.

La idea, al fin y al cabo, es tener un sistema que sea fácil de seguir y que permita identificar fácilmente los elementos que se estan utiizando en consultas, los que se referencia en mensajes de error, en relaciones entre elementos etc.

Resaltar especialmente que este es el sistema que YO utilizo, pero hay muchos otros cada uno con sus pros y sus contras y no es mi intención decir que es el mejor ni nada remotamente parecido. En este caso, se cumple el dicho de que para gustos, colores y la organización o el DBA son los responsables de escoger entre la cantidad de opciones disponibles.

.- El primer punto es sencillo, escoger tres letras como alias de "la aplicación" o módulo a desarrollar. Por ejemplo, si vamos a trabajar la parte de almacén y no se ha usado ya ese "álias", podríamos escoger ALM como álias de aplicación.
.- Una vez escogido el primer punto, las tablas empezarían con T + dicho álias, las vistas con V + álias, las restricciones de integridad con K + álias, los índices con I + álias... etc. Así pues, la tabla para representar los productos en la aplicación sería TALM_PRODUCTO, la de clientes TALM_CLIENTE y así sucesivamente. Los nombres siempre en singular y sin abreviar a no ser que la longitud sea muy muy larga. Hoy en día restringir los nombres a 8 caracteres o menos como se hacía antes tiene muy poco sentido.
.- Dentro de las tablas, yo prefiero utilizar siempre un identificador único e inventado sin significado de negocio, siempre con el mismo nombre y el mismo tipo. Además, cada tabla tiene su propio álias y se añade delante de todos los nombres de los campos. Por ejemplo, la tabla TALM_CLIENTE, con alias CLI, tendria los campos CLI_ID, CLI_NOMBRE, CLI_NIF..., la de productos tendria PRD_ID, PRD_NOMBRE, PRD_CODIGO... Darse cuenta de que PROD_ID sería un identificador inventado y que el número que viene en el producto sería por ejemplo PRD_CODIGO. Existen múltiples discusiones a favor y en contra de usar o no identificadores inventados y no voy a intentar convencer a nadie. Sólo decir que tener que detener la operación del sistema periódicamente para poder anular las restricciones de integridad para solucionar los problemas de errores en los identificadores no inventados da una perspectiva diferente :). No voy a decir que no tenga inconvenientes o que el sistema esté mal hecho si no se sigue. Sólo puedo decir que cuando puedo elegir, YO lo hago así. Siguiendo con lo ya mencionado, la restriccion de clave primaría tiene el alias de la aplicacion y de la tabla seguido del sufijo _PK, para indicar que es "primary key". Por ejemplo, para la tabla TALM_CLIENTE sería KALM_CLI_PK, para TALM_PRODUCTO sería KALM_PRD_PK etc.
.- Las claves extranjeras simplemente referencian el campo en la tabla "remota" añadiendo el prefijo correspondiente y sólo en caso de existir más de una clave extranjera contra la misma tabla se añade un sufijo para diferenciarlas. Por ejemplo, en la tabla TALM_STOCK, tendríamos una clave extranjera a TALM_PRODUCTO bajo el nombre STK_PRD_ID, en TALM_FACTURA tendríamos FAC_CLI_ID para referenciar el cliente... etc. Como se puede ver esto facilita enormente la identificación de los elementos de cada relacion, incluso permite automatizar algunas tareas. Por otro lado, las restricciones de integridad de las claves extranjeras indican en este caso ambas tablas y el sufijo _FK, de "foreign ey". Las restricciones para los ejemplos mencionados serían KALM_STK_PRD_FK y KALM_FAC_CLI_FK. De este modo, al violar una de estas claves, el mensaje de error ya nos indicará claramente cuales con las tablas implicadas.
.- Las restricciones sobre campos indican el nombre del campo y el tipo de restriccion, por ejemplo PRD_CODIGO sería un campo seguramente único y como tal tendría la restriccion KALM_PRD_CODIGO_UK (de "unique key"), las restricciones de integridad serían igual pero con _CHK al final etc.

Ese es básicamente el estilo de nomenclatura que sigo y con el que me siento comodo, aunque no soy muy talibán al respecto.

A la hora de trasladar el modelo de datos a clases Java los prefijos desaparecen y uso un estilo de nomenclatura más "javero" y así de esta forma cada mundo es coherente y sigue sus propias reglas. Eso implica que siempre tengo que especificar los nombres de los elementos que corresponden en cada caso, pero es una "molestia" que tengo automatizada y no me importa pagar ese precio. La razoón para no tener que usar tanto sufijo en Java es que con la estructuración en paquetes y el estilo de los errores ya da suficiente información como para poder situarte rápidamente sin necesitar esas ayudas.

No intento convencer a nadie de que use nada pero por si a alguien le da alguna idea y/o le sirve, ahí queda dicho. Y una vez dicho esto...¿Usais vosotros, estimados lectores, algún tipo de estilo/estándar de nomenclatura?

Happy coding! EJ

PD: Ah, feliz año nuevo ;). A ver si este 2011 nos trata un poco mejor a "la plebe" y un poco peor a los chupasangres del mundo.