El sano ejercicio de cuestionar lo incuestionable

Los profesionales de BI vemos con asiduidad desarrollos hechos hace años (o no tantos) y nos echamos las manos a la cabeza. ¿Pero a quien se le ocurrió guardar los años en campos de dos dígitos? ¿Qué carajo es el campo PRRFCOL de la tabla TBFPPRES?

Probablemente, esas prácticas de nomenclatura (u otras similares de diseño…) tenían su sentido cuando se definieron y se empezaron a utilizar… Lo cuestionable es que esas mismas prácticas se perpetúen fuera de toda lógica. No solo la persona que las definió en su día las sigue utilizando, sino que esas mismas reglas son seguidas por la gente joven que se incorpora… y hasta pueden exportarse a otras organizaciones y otras tecnologías por la fuerza de la costumbre… Estoy seguro que conoces “patrones” absurdos que se utilizan y resulta complicado cambiar o incluso cuestionar (te animo a que los expongas en los comentarios, si quieres…).

Pero hoy no vengo a criticar cómo trabajan los demás si no a plantear si similares objeciones podrán hacerse sobre los trabajos que estamos haciendo hoy en día y que consideramos que siguen “buenas prácticas”. ¿Qué cosas hago por pura tradición sin cuestionarme si tienen sentido o aportan valor?

En este artículo me centraré en el tema de nomenclatura, pero creo que es un ejercicio de autocrítica valioso que podríamos ejercitar en cualquier otro ámbito de nuestro trabajo…

Veamos un ejemplo muy concreto referente al uso de espacios en los nombres:

• ¿Por qué no ponemos espacios ni acentos en el nombre de las tablas, campos, índices o procedimientos? Antes de saltar a la yugular piensa en todas las yugulares que fueron mordidas a los que cuestionaron si las tablas tienen que nombrarse con 8 caracteres o si aporta algo utilizar la ya muy desprestigiada notación húngara para las variables… ¿Por qué con el nombre del responsable comercial preferimos llamarlo RepsonsableComercial, RespComercial, Responsable_Comercial…?
• ¿Por qué incluso nos resistimos a poner espacios en el nombre de los archivos? Sabes_de_Lo_que_hablo.docx.

Lo que propongo es que el nombre de las entidades y atributos de un Data Warehouse (por poner un ejemplo) sean descriptivos, con lenguaje de negocio, y por supuesto con los espacios y la acentuación correspondiente. ¿Qué problema hay en que la tabla de “Países” se llame “Países”? ¿Qué problema hay con que un campo se llame “Responsable comercial” o “Comunidad autónoma”…?

Pensemos que probablemente los nombres que pongamos en estas entidades se arrastrarán a las capas semánticas, a los informes, a los front-ends del usuario… Tarde o temprano, y probablemente múltiples veces, alguien deberá convertir los nombres técnicos en nombres de negocio, y lo que propongo es realizar esta conversión cuanto antes. En el modelo de datos. Por supuesto, estos nombres no suponen ningún problema tecnológico hoy en día.

Para que nadie piense que casualmente estoy proponiendo extrapolar mis criterios para su uso generalizado aclaro que jamás he utilizado aún este criterio de nomenclatura. Lo que me pregunto, lo que os pregunto, es: ¿Por qué no? ¿Por qué?

PD: Por cierto, en Crono, cómo sabemos que las prácticas vigentes existen, al crear la metadata los campos se humanizan automáticamente (es decir, si el campo en origen se llama ResponsableComercial, o Responsable_Comercial, al arrastrarse se convierte automágicamente en "Responsable comercial"). Una cosita que junto tantas otras facilita el desarrollo de manera significativa...