Al González
22-04-2007, 01:44:58
¡Hola a todos!
El motivo de este mensaje es plantearles cierta idea que tengo con un par de proyectos y pedirles su consejo acerca de cómo resultaría mejor implementar dicha idea.
Simplifiquemos el escenario:
Base de datos Firebird 1.5, de tres a 10 clientes conectados a ella.
Considérese una tabla ARTICULOS con 150 mil registros.
Delphi 7, tres capas (por ahora "2.5") usando la siguiente asociación de elementos:
Procedimiento almacenado --> TSQLConnection --> TSQLQuery --> TDataSetProvider --> TClientDataSet --> TDataSource --> TcxGrid (poderosa QuantumGrid de Developer Express).
Tradicionalmente, si utilizara el típico componente TDBGrid para mostrar los datos, éste se encargaría de ir solicitando registros al conjunto de datos conforme el usuario navegara hacia abajo, de tal manera que no tendría que cargar todo el cursor en un sólo acto, sino sólo segmentos del mismo según fueran necesitándose, economizando tiempos y recursos. Incluso creo (no estoy muy seguro) que para ello se utiliza la propiedad TClientDataSet.PacketRecords.
Pues bien, resulta que mi deseo es cargar todos los registros de la tabla en memoria para que el usuario aproveche al máximo las capacidades de la rejilla TcxGrid. Con ésta, el usuario puede ordenar la información por diferentes columnas, establecer filtros, agrupar, realizar búsquedas especiales, exportar a Excel, etc. Una gran variedad de tareas que difícilmente se lograrían mediante puras sentencias SQL.
Aclaro que no me interesa discutir el asunto del consumo de recursos, las reglas de los cánones y todo lo que dice la literatura tradicional. He evaluado el costo-beneficio de cargar toda la tabla en memoria, y, para los propósitos específicos de la aplicación, veo que vale la pena (aún si tuviese el doble de registros).
Sólo que hay un problema: Demora alrededor de cuatro minutos en cargar la tabla. Y quiero atenuar ese costo.
Para ello he considerado implementar un mecanismo por el cual el usuario pueda trabajar con la interfaz, mientras que, en segundo plano (con un segundo hilo —thread—) la tabla se carga por completo. Pondría en alguna esquina de la ventana una barra de progreso indicando el porcentaje de avance de la carga, pero me gustaría que el usuario pudiera "jugar con" (manejar) la información que hasta el momento se haya cargado.
Estoy conciente de que esto no solucionaría del todo el problema de la disponibilidad inmediata de la información (y habrá otras cosas que tendré que implementar para compensar), pero cuando menos no bloquearía la interfaz de usuario durante los procesos de carga. El usuario, en ciertas interfaces, será conciente de que la carga puede demorar algunos minutos (como bien ya sucede con grandes archivos de Excel que muchos usuarios esperan pacientemente a que se carguen para, ya estando la información en memoria, realizar una gran variedad de tareas con dicha información).
Algo me dice que el método TClientDataSet.CloneCursor podría estar involucrado en el mecanismo a implementar para esta idea. Pero no quisiera adelantarme más a las recomendaciones que ustedes pudieran hacerme.
De antemano gracias por sus valiosos comentarios. Estaré atento a sus respuestas.
Un abrazo rápido.
Al González. :)
El motivo de este mensaje es plantearles cierta idea que tengo con un par de proyectos y pedirles su consejo acerca de cómo resultaría mejor implementar dicha idea.
Simplifiquemos el escenario:
Base de datos Firebird 1.5, de tres a 10 clientes conectados a ella.
Considérese una tabla ARTICULOS con 150 mil registros.
Delphi 7, tres capas (por ahora "2.5") usando la siguiente asociación de elementos:
Procedimiento almacenado --> TSQLConnection --> TSQLQuery --> TDataSetProvider --> TClientDataSet --> TDataSource --> TcxGrid (poderosa QuantumGrid de Developer Express).
Tradicionalmente, si utilizara el típico componente TDBGrid para mostrar los datos, éste se encargaría de ir solicitando registros al conjunto de datos conforme el usuario navegara hacia abajo, de tal manera que no tendría que cargar todo el cursor en un sólo acto, sino sólo segmentos del mismo según fueran necesitándose, economizando tiempos y recursos. Incluso creo (no estoy muy seguro) que para ello se utiliza la propiedad TClientDataSet.PacketRecords.
Pues bien, resulta que mi deseo es cargar todos los registros de la tabla en memoria para que el usuario aproveche al máximo las capacidades de la rejilla TcxGrid. Con ésta, el usuario puede ordenar la información por diferentes columnas, establecer filtros, agrupar, realizar búsquedas especiales, exportar a Excel, etc. Una gran variedad de tareas que difícilmente se lograrían mediante puras sentencias SQL.
Aclaro que no me interesa discutir el asunto del consumo de recursos, las reglas de los cánones y todo lo que dice la literatura tradicional. He evaluado el costo-beneficio de cargar toda la tabla en memoria, y, para los propósitos específicos de la aplicación, veo que vale la pena (aún si tuviese el doble de registros).
Sólo que hay un problema: Demora alrededor de cuatro minutos en cargar la tabla. Y quiero atenuar ese costo.
Para ello he considerado implementar un mecanismo por el cual el usuario pueda trabajar con la interfaz, mientras que, en segundo plano (con un segundo hilo —thread—) la tabla se carga por completo. Pondría en alguna esquina de la ventana una barra de progreso indicando el porcentaje de avance de la carga, pero me gustaría que el usuario pudiera "jugar con" (manejar) la información que hasta el momento se haya cargado.
Estoy conciente de que esto no solucionaría del todo el problema de la disponibilidad inmediata de la información (y habrá otras cosas que tendré que implementar para compensar), pero cuando menos no bloquearía la interfaz de usuario durante los procesos de carga. El usuario, en ciertas interfaces, será conciente de que la carga puede demorar algunos minutos (como bien ya sucede con grandes archivos de Excel que muchos usuarios esperan pacientemente a que se carguen para, ya estando la información en memoria, realizar una gran variedad de tareas con dicha información).
Algo me dice que el método TClientDataSet.CloneCursor podría estar involucrado en el mecanismo a implementar para esta idea. Pero no quisiera adelantarme más a las recomendaciones que ustedes pudieran hacerme.
De antemano gracias por sus valiosos comentarios. Estaré atento a sus respuestas.
Un abrazo rápido.
Al González. :)