Pensar en listas
Hoy en día la gran mayoría de personas usamos a diario algún tipo de aplicación. Casi todas las aplicaciones gestionan información y disponen de interfaces adecuados para conseguir la mejor experiencia de usuario posible.
A nivel de interfaz como usuario solemos navegar por la información igual que lo hacemos en un mapa, que no deja de ser un tipo de información que nos hemos acostumbrado a visualizar de forma gráfica, es decir solemos comenzar con un mapa general sobre el que vamos haciendo zoom para acercarnos y ver con detalle solo aquello que realmente nos interesa.
Navegar por la información
Como usuarios esta navegación por los datos se realiza casi siempre comenzando con un modo de visualización de lista. Cada vez que usamos un buscador en Internet estamos esperando que nos devuelva una lista, tenemos claro que no sería una interfaz óptima el que nos mostrase la primera página web e ir moviéndonos hacia adelante o hacia atrás con los botones de flechas o teclas aceleradoras hasta encontrar la información que buscamos.
En las aplicaciones de gestión sucede lo mismo. El usuario no necesita ver con detalle toda la información, sino que necesita partir de una lista inicial para ir filtrando con diferentes criterios hasta obtener una lista lo más pequeña posible para que sea manejable y es en ese momento cuando sí que interesa entrar en el detalle.
Ejemplo de facturas
Un ejemplo de lo anterior podemos verlo en cómo buscar una factura concreta partiendo de que conocemos el cliente al que se le emitió y el artículo que se le vendió. Si buscamos todas las facturas podemos obtener una lista de cientos, miles o incluso millones de registros por lo que el primer criterio a aplicar será el cliente y así podremos obtener una lista con solo las facturas del cliente, si la lista sigue siendo grande, más de 50 registros, puede ser conveniente filtrar entre fechas para reducir la lista inicial. Si en alguno de los pasos obtener una lista con una única factura nuestro destino estará muy cerca, en caso contrario es posible que tengamos que entrar una a una en las diferentes facturas de la lista hasta localizar la que nos interesa.
Si esta búsqueda fuese muy habitual deberíamos mejorar la interfaz de nuestra aplicación para facilitar al usuario su experiencia. Sin duda, la forma más rápida y directa en nuestro ejemplo sería poder buscar a la vez por el cliente, el artículo y el período de fechas deseado. De esta forma con una única búsqueda habríamos obtenido la lista que cumple todos nuestros criterios.
Ahora bien, para seleccionar nuestros criterios de búsqueda estaríamos obligando al usuario a localizar un cliente concreto, y luego un artículo concreto. Estas “mini” búsquedas en realidad son diferentes pasos para el usuario final.
Mejorando la interfaz
Podemos mejorar si en una misma interfaz le pedimos que escriba parte del nombre del cliente y del artículo, al más puro estilo del buscador de Google y que pueda rellenar también las fechas desde-hasta del periodo.
Desde el punto de vista del programador esto se puede conseguir buscando clientes por trozos del nombre y luego artículos por trozos de su nombre o descripción, sin embargo, se nos plantea un problema a resolver, si solo tenemos un único control para escribir partes del nombre del cliente y del artículo, ¿Cómo sabemos que trozos de textos son del cliente o del artículo?, realmente no lo sabemos por lo que probablemente acabaríamos poniendo 2 controles de edición alfabéticos en uno pediríamos el texto para buscar el cliente y en el otro el texto para buscar el artículo.
A nivel de programación para optimizar su rendimiento estaríamos obligados a ejecutar todas las búsquedas en 3º plano con el fin de obtener la lista en el menor tiempo posible. Aún así seguimos teniendo otro problema para resolver. La lista que queremos mostrar es de facturas, por lo que si buscamos un cliente, luego tenemos que localizar sus facturas, pero cuando buscamos el artículo, luego tenemos que cargar todas las líneas de facturas donde esté incluido y con esas líneas de detalle navegar a las cabeceras de factura para obtener la lista de facturas. Así que tras buscar las facturas del cliente entre fechas y luego las facturas donde se vendieron esos artículos estaríamos obligados a cruzar ambas listas para conseguir la lista final a mostrar al usuario.
Como vemos en el párrafo anterior, al final esta búsqueda se ha ido complicando hasta el punto de tener que optimizar bien nuestra programación para reducir al máximo las búsquedas y que todas las operaciones se realicen en el servidor para evitar el envío de información al cliente hasta que tengamos la lista definitiva.
Optimizar la solución
¿Y si hubiese una forma de buscar todo a la vez en una única búsqueda? Con Velneo puedes conseguirlo. Puedes crear una interfaz de búsqueda donde pidas un único texto donde el usuario escribirá los trozos de texto del nombre del cliente y del artículo y los dos controles de edición de fecha desde y hasta. Podemos incluso detectar cuando se van rellenando los datos de búsqueda y lanzar automáticamente la búsqueda sin obligar al usuario a pulsar un botón buscar.
A nivel de programación tendremos una única búsqueda con dos componentes, el primero buscará las facturas entre las fecha desde y hasta, si el usuario las específico, y el segundo buscará las facturas en las que el nombre del cliente y del artículo se correspondan con los trozos escritos por el usuario, la búsqueda se encargará de cruzar ambas listas y devolvernos de forma instantánea la lista de facturas que busca el cliente.
¿Cómo podemos conseguir que Velneo me devuelva facturas buscando por trozos de texto del nombre del cliente, dato que no está en la factura sino en el registro de cliente enlazado? y, más difícil aún, ¿Cómo podemos conseguir que a la vez busca por los trozos del nombre de los artículos que está en la tabla de artículos que a su vez es un registro enlazado desde las líneas de detalle de la factura que a su vez son una lista de registros enlazados a la cabecera de factura?
Usar índices complejos
La solución se llama índice complejo. Es un tipo de índice especial de la base de datos de Velneo que tiene la capacidad de indexar registro de una tabla, en nuestro ejemplo de facturas, por los trozos del nombre del cliente y de los artículos de las líneas de detalle de las facturas. Si lo piensas bien resulta asombroso.
Lo mejor de todo es que la definición del objeto índice complejo es muy sencilla y su uso es igual que la de cualquier índice. El único handicap de este tipo de índices es que en función de lo que indexemos y del número de registros pueden tener un tamaño elevado en disco. Por este motivo es conveniente no hacer un uso incontrolado de este tipo de índices.
Disfruta de una gran experiencia de usuario
Desde el punto de vista del usuario el resultado es magnífico, busca de forma instantánea facturas por criterios realmente complejos pudiendo incluso buscar aquellas facturas de un cliente que contengan varios artículos en la misma factura.
Aunque como usuarios nos acostumbramos rápidamente a lo bueno y tampoco llegamos a valorar técnicamente lo que hay por debajo, como programadores sí que podemos llegar a disfrutar de lo que ponemos en manos del usuario gracias a un esfuerzo de diseño de base de datos en lugar de tener que dedicar muchas horas de programación.
Deja una respuesta