Un alto porcentaje de las aplicaciones de gestión contienen información de provincias y poblaciones para el registro de direcciones de clientes, proveedores, trabajadores, agentes, etc. Guardar el contacto de estas personas es vital para el envio de facturas, recibos o cartas por correo ordinario.

Existen diferentes formas de crear esta información de poblaciones y provincias en tu aplicación para este envio de correo ordinario o gestión y organización de tus dátos desde el punto de vista demográfico. Esta información puede estar guardada tanto de manera más libre y desnormalizada para los casos en el que esta información no sea vital para tu negocio, hasta obtener información de fuentes públicas o profesionales. Veamos cada una de ellas reflexionando sobre sus inconvenientes.

1. Diseño no normalizado (la solución más barata)

Una de ellas es no normalizarlo de manera que en la alta en la ficha se introduzca el campo en texto abierto. De esta manera el usuario puede escribir cualquier población o provincia sin necesidad que esté dado de alta en una tabla maestra. Esta forma de desarrollar es la más fácil ya que no requiere más código funcional adicional que poner unos campos en la tabla de las personas donde queremos guardar su información. Esta forma de diseño tiene varios problemas:

• Problemas para los informes o estadísticas: Nadie controla que se introduce en estos campos por lo que puede que se escriba una misma población de diferentes formas: con o sin acentos, cambiando el orden de los artículos, quitando artículos, con faltas tipográficas, etc. Esto es un problema a no ser que un día concreto desees sacar unas estadísticas o informes demográficos de la actividad de tu empresa.

• Búsqueda de poblaciones por el usuario: También puede que sea necesario por parte del usuario la búsqueda de una tienda o servicio ubicado en un sitio concreto en la que tenemos multitud de oficinas. Por ejemplo, hoteles, bancos, centros deportivos, etc. En esta ocasión no es el propietario de la aplicación quien desea conocer el dato, si no que es el propio usuario quién realiza la búsqueda por la población o provincia. En este caso, si tu base de datos no está normalizada, existe el riesgo de errar en los datos y que el cliente final no encuentre esta entidad.

2. Diseño normalizado y gestionable (solución habitual)

La otra opción que tenemos es tener un diseño normalizado. Un diseño normalizado es aquel en el que los datos no van abiertos en los propios registros en el caso de repetirse, si no que van reglados por una o varias tablas adicionales llevando un identificador. Esta forma de diseño evita errores tipográficos pero también pueden existir problemas:

• Necesidad de una gestión de poblaciones y provincias: Será necesario que el usuario pueda configurar sus poblaciones y provincias. Para ello será preciso que exista una ventana adicional donde pueda de dar de alta, baja y modificación estos datos. Una forma de árbol (componente treeview) puede ser una solución interesante desde el punto de vista de usabilidad para poder gestionar esto en un único formulario. Aún así, existen otras formas de diseño de formularios también útiles para dar de alta estos registros.

• No tener actualizada la base de datos: Para poder gestionar las poblaciones y provincias tiene un problema adicional que es no disponer de una base de datos completa. Una solución para esto es dar de alta la población o provincia por parte del usuario en el caso de no encontrar el registro. Sin embargo, aunque esta es la opción más lógica y usable, puede darse el caso de que un usuario no encuentre una población por un fallo tipográficos que realmente si esté dado de alta en la base de datos. Esto provocará a largo plazo a tener poblaciones repetidas bajo diferentes nombres.

3. Tablas normalizadas usando fuentes públicas (La solución menos mala en relación coste/beneficios)

La solución ideal es tener la base de datos normalizada pero obtener los datos de las poblaciones de recursos profesionales o revisados convenientemente. Encontrar una base de datos así no es tarea fácil. Una posible fuente de datos pueden ser los datos del Instituto Nacional de Estadística donde aparecen totales demográficos por municipios. Otra posible fuente de datos la publicó recientemente Javier Casares a través de su blog donde se ofrece una base de datos bastante completa en el que se disponen de una tabla provincias y otra de poblaciones, así como información del código postal, latitud y longitud de la ubicación.

Con esta solución es más completa aunque no podemos encontrar con problemas si el cliente, ya sea persona o entidad, proviene de un país extranjero en el que nosotros no tengamos esta información en nuestra base de datos.

4. Permitir todas las opciones (La solución ideal ante la duda … y la más cara)

La solución definitiva para contemplar todos los posibles casos. Para ello se tendrían unas tablas de poblaciones y provincias. Sería aún más correcto (y más caro) tener esta información de manera multinivel. De esta forma se podrían incorporar términos como Comunidad Autónoma o niveles que puedan existir en otros paises que sean diferentes al estado español.

Además en esta solución ideal, el usuario final podría escribir un texto abierto en el caso de no encontrar su población. De esta manera dejamos solucionado el problema de no tener actualizado la base de datos. Pero este registro deberá ser marcado para que un trabajador revise estos y normalice los datos a posteriori comprobando los datos y actualizando la base de datos.

Opinión personal

Desde mi punto de vista, la gestión de países, provincias y poblaciones es un tema complejo que su gestión debe depender de los beneficios que te van a aportar. Posiblemente un consultor externo para asegurarse de tener todo contemplado recomendará la solución ideal. Me he topado muchas veces con la actitud de muchos consultores y personal no técnico de decir que ante la duda, que se contemple todo. Pero en mi opinión, no se trata siempre de tomar la solución ideal, si no de cual se aproxima más a tus necesidades conociéndolas y en caso de dudas ir por lo más barato y fácil. Por ello, cualquier solución puede ser buena dependiendo de tus necesidades.

Tanto en este caso como en todos intenta elegir la solución según tus necesidades y recursos que no son infinitos y están limitados por tu entorno. Debes tener en cuenta que un diseño erroneo puede hacer que no puedas aplicar tu funcionalidad o por el contrario que el coste de desarrollo se incremente con funcionalidades no utilizadas.

Recurso para obtener lista de poblaciones | Instituto nacional de estadística
Recurso para obtener lista de poblaciones | Blog de Javier Casares
Imagen CC | Autor: duboix – Fuente: http://www.morguefile.com