¿Es apropiado un ListView para mostrar 40.000 líneas?

[Angel Fernández]

Muchas gracias por vuestra ayuda.

Os cuento con un poco más de detalle lo que quiero hacer por si alguien lo ha hecho antes.

Tengo una consulta sobre una BD de firebird que almacena datos de una serie de sensores de temperatura. La consulta me devuelve un listado parecido a esto:

Fecha Hora Sensor Dato
---------------------------------------------
01/01/2008 00:01 001 30.00
01/01/2008 00:01 002 31.00
01/01/2008 00:01 003 32.00
01/01/2008 00:02 001 35.00
01/01/2008 00:02 002 36.00
01/01/2008 00:02 003 31.00
01/01/2008 00:03 001 30.00
01/01/2008 00:03 002 32.00
01/01/2008 00:03 003 32.00
....
El número de datos de la consulta puede variar entre 1.000 y casi 50.000.


Y lo que quiero conseguir es esto:

Fecha Hora Sensor001 Sensor002 Sensor003
--------------------------------------------------------------------
01/01/2008 00:01 30.00 31.00 32.00
01/01/2008 00:02 35.00 36.00 31.00
01/01/2008 00:03 30.00 32.00 32.00
...

Para hacer eso necesito recorrer toda la consulta e ir colocando los datos en un listview.

Una vez lo intenté con una tabla temporal de las utilidades rx. Recorría la consulta y los iba colocando en la tabla colocados por sensor. Luego lo mostraba con un DBGrid, pero este proceso era lentísimo (cada vez que hacía post en la tabla temporal, perdía unas décimas que, sumadas, hacían un total escandaloso).


¿Alguien se ha encontrado con esta necesidad antes? ¿El listview os sigue pareciendo bueno o hay otro modo que se me escapa?

Un saludo.

[dec]

Hola,

Lo que no puede ser es que pidas a la base de datos 50.000 registros "de una tacada". Eso sólo ya ralentizaría la aplicación sin remedio. ¿Por qué no usar algún tipo de limitación en la consulta SQL, y dar al usuario la posibilidad de "navegar" por los registros? Lo que se conoce como "paginación", porque, pienso que además no tiene sentido traer 50.000 registros de la base de datos, ¿quién iba a revisar todos esos registros además? Así que me parece que habría que ver de paginar esos registros, de irlos trayendo poco a poco. Por lo menos así opino yo.

[[AzidRain]]

Esto de las bases de datos y las "listas" sea cual fuere su tipo (listviews o grids o lo que sae) es un viejo dilema que pocos nos ponemos a analizar y que muchas veces provoca que desarrollemos soluciones poco prácticas.

En tu caso, se trata de consultar un simple log de instrumentación ( un sensor). Normalmente siempre caemos en la tentación de listar todo y que el usuario se ponga a buscar en él. A veces se nos ocurre ponerle un buscador para que encuentre un dato o línea en particular. Me permito hacer la analogía con un listado telefónico: ¿Que sería más útil? ¿Un programa que nos muestra TODO el listado con los miles y miles de registros o uno que nos permita indicarle filtros de búsqueda como nombre o apellido...?

La respuesta es obvia, de tal suerte que si el listado que vamos a mostrar no pasa de al menos unas 30 líneas digamos que es razonable mostrar todo sin filtrar, pero si no sabemos o bien el listado puede llegar a medir varios miles de líneas, no tiene sentido mostrarlas todas.

Te recomiendo que en vez de mostrar todo de un jalón, le pongas algunos filtros para que el usuario escoja la información que requiere consultar más precisamente, por ejemplo:

Preguntar al usuario (usando los controles que te parezcan mejores:
Que rango de Fechas
Entre que Horas
Que sensor(es)

Si analizamos normalmente en este tipo de aplicaciones el usuario desea saber casi siempre algo como:

"Quiero saber que temperatura registro el sensor 1 entre las 14 y las 14:30 de ayer ya que fue la hora en que hubo un fallo en la caldera"

Analizando tu otra respuesta lo que necesitas es corregir el query que estás haciendo para que no necesites hacer un reproceso sobre todos los registros.

Haciendo ambas cosas sin duda reducirás mucho tanto el tiempo como el tamaño de los listados.