Las tablas de código – valor.

En general en los sistemas de información se tienen muchos atributos cuyos dominios de valores son enumeraciones discretas de posibles valores, a veces acotado a un número finito, y a veces muy reducido de posibles valores. Los sistemas de información con que se administran tributos no son una excepción. En el registro de contribuyentes, por ejemplo, registramos que el género de un individuo puede ser masculino o femenino, únicamente; o que el tipo de personas pueden ser naturales, nacionales o extranjeros, o jurídicas con una variedad de sabores que permite distinguir a compañías anónimas, o de responsabilidad limitada, a comanditas simples o por acciones, a sociedades de hecho, y que en algún país superan de largo la decena.

Al construir las soluciones, se creaba una tabla de posibles valores, cada valor con un código corto. Así una tabla de tipo de persona natural podría tener registros del tipo ‘N’ – Nacionales, y ‘V’ – Extranjeros; pero podría ser que en otro caso se use 1, o 2 en lugar de la V o la N; y con la decena larga de tipos de jurídicas: la inicial sola no alcanza. De esta manera, en un millón de registros, se ahorran unos millones de bytes.

Fue un amigo, chileno de Punta Arenas, quien me planteó por primera vez, su visión sobre ese criterio: debía revisarse. La charla ocurrió al final de una tarde en una oficina de las Torres del Silencio, en Caracas. Me decía Ernesto que los valores con que esos campos debían representarse debían corresponder exactamente con su significado, que los códigos que representen masculino y femenino, debían ser los mismos sustantivos, que los códigos que representen a operaciones como crear o actualizar, deberían ser los mismos verbos.

Decía Ernesto, que lo único que se pierde es espacio. Pero que había espacio para ganar mucho; las aplicaciones y hasta las consultas más simples a la base de datos se simplifican notablemente al no tener que realizar siempre una referencia a la tabla de campo valor para hacer la corrección. La posibilidad de escribir mal un código se controlaría de la misma manera con que se controla el escribir bien un número o letra, es decir validando que estén en el rango; sea con una restricción o con una referencia foránea a otra tabla que todavía existiría. La mayor ventaja, decía él, es que quien llegue nuevo no tiene que consultar y aprender lo que significa un “1”, o en su defecto saber dónde buscarlo. La sola lectura del campo indica su valor.

Los sistemas que han evolucionado desde el pasado seguramente mantienen ese modelo. Estoy seguro que algunos sistemas nuevos conservarán la tradición. Pero algunos sistemas que se desarrollan hoy usan para esas tablas de valores finitos los mismos conceptos, como lo sugería Ernesto. Hoy, por ejemplo, los valores de atributos que se usan generalmente en nodos XML y que podrían tomar solo uno de un conjunto finito de valores suelen expresarse con el nodo o verbo completo. El tipo de un campo de entrada  en HTML no es 1, 2, o3, y sí botón, caja de chequeo, oculto, botones de radio, etc. Siendo SVG una clara excepción.

Los últimos sistemas que construí tienen esa característica. Además se ganó algo: con ese esquema cambié también las tradicionales interfaces de mantenimiento (eso que a veces se llama CRUD). En lugar de tener botones para, uno a uno, crear, actualizar o eliminar un registro; se puede actualizar toda la tabla de una vez: sea con un solo campo de edición en que se presente la lista de valores separada por comas, o a través de un XML. Da un poco más de trabajo, pero al usuario que mantiene esas tablas, le gustó mucho.

Saludos y suerte.

5,073 total views, 3 views today