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

Hola a todos. Quería preguntar si alguien ha utilizado un listview para mostrar gran cantidad de información. Con gran cantidad me refiero a unas 40 columnas y entre 30.000 y 50.000 líneas (cincuenta mil líneas).
Me gusta el listview porque es un componente muy limpio visualmente y se puede seleccionar una fila completa, que me viene muy bien para lo que quiero. Por contra, un stringGrid no me gusta: feo y tosco.

¿Es apropiado un Listview para eso? En caso contrario ¿algún otro componente que uséis?

Utilizo D7 bajo windows xp.

Gracias y un saludo.

Poder, si puedes... pero cargar todos estos datos, va a tardar un poco (teniendo el refresh bloqueado mientras se carga).

Código Delphi [-]
ListView1.Items.BeginUpdate;
// aqui añades todos los items
ListView1.Items.EndUpdate;

Saludos.

Lo recomendable es cargarlo en modo virtual, por ejemplo, el bloc de notas de windows lo hace como tú dices, (cargarlo todo de un tirón) y hasta que no termina de cargar, no puedes hacer nada con el programa.

En forma virtual quiere decir que sólo cargas el primer megabyte (por decir algo) y cuando el usuario hace un scroll, es cuando se carga lo demás. O incluso vas cargando en segundo plano y vas llenando el control, (pero el usuario puede ir trabajando con lo ya cargado. Para esto se usan los TStream que son eficientes y rápidos, échale un vistazo a la ayuda y busca por el foro, hay bastante sobre ellos.

Yo quizás haría uso de un TreeView + grid, pero depende de qué vayas a cargar y cómo lo quieres presentar.

Saludos

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.

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. ;)

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.

Hola.

Personalmente creo que lo que no es adecuado, es mostrar 50.000 líneas; Independientemente del componente.
No se exactamente cual es la necesiad de mostrar esa cantidad de información, pero salvo que sea algo muy especial, soy de los que piensa que mostrar más de 200 o 300 líneas a un usuario es inútil (siempre puede haber alguna excepción).
Nadie va a recorrerse 50.000 líneas buscando algo. ¡Es absurdo!

Puedes tener 50.000 registros, pero al usuario debes hacerle que acote los datos, que use filtros,... para mostrarle menos.


Que se seleccione toda la línea es una propiedad del componente. Si modificas un poco el StringGrid (1, 2, 3, 4, ...), puedes conseguir que sea casi igual o mejor que cualquier otro componente.

Otra opción es usar algo como esto o esto.

Gracias a todos por vuestra ayuda y comentarios.

Ciertamente, tenéis razón en cuanto que mostrar 50.000 registros es excesivo. He exagerado un poco, no serán 50.000 registros, sino más bien como mucho 20.000. En cualquier caso, da lo mismo: eso no lo puede digerir ninguna mente humana.

Pero en este caso en concreto, lo que yo hago con los miles de datos de la consulta es recorrerlos y hacer un gráfico en el que se ve claramente la evolución de las temperaturas y si hay un pico o un valle localizar en qué fecha se produce tal incidente. Y son los datos de ese incidente (pico o valle) - y unos pocos datos más por arriba y por abajo para poner en contexto el dato problemático - los que me gustaría poner en forma de lista, para ser más "entendibles". Lo que habéis dicho me ha hecho reflexionar y quizá una buena solución sea lo que apunta Azidrain: poner en forma de lista sólo unos cuantos datos, a petición del usuario cuando localice un incidente.

Un saludo. Vuestros comentarios me ayudan mucho.

P.D: Lepe, si puedes ¿podrías indicarme algún hilo de este foro donde se profundice en los TStream? He buscado y he encontrado muy poca cosa buscando por el título y muchas por contenido. La ayuda de delphi tampoco me aclara mucho.
Aunque quizá no lo use para este proyecto en concreto, me parece muy interesante su uso. Por ejemplo: ¿cómo cargo progresivamente un listview conforme se desplace la barra lateral?

Una pregunta
¿para que se necesita mostrar los datos para hacer un gráfico y para mostrar los picos o valles?

Saludos

Ya que los tengo para hacer el gráfico ¿por qué no mostrarlos? Otra cosa es que el usuario me diga que le marea tanto dato y que sólo quiere ver el gráfico; entonces le doy la opción al usuario de ver sólo el gráfico.

Pero lo que sí quiero mostrar en forma de lista son los datos que el usuario quiera estudiar con más detalle (un pico, un valle, lo que sea).

Un saludo.

Lo que él quiere es primero mostrar el gráfico y donde aparezcan picos (o en cualquier parte que el usuari quiera) que con un click o algo similar nos muestre un listado de las temperaturas registradas por los sensores alrededor de ese momento.

Podrían ser por ejemplo las lecturas de los últimos 5 minutos antes y después del pico.

Aquí tienes un ejemplo y explicación de TStream y derivados.

El concepto es simple: Tienes una cantidad de información (da igual si binario, texto, ...lo que sea, incluso puedes mezclar ambos en el mismo Stream) y lo envias a un descendiente de TStream:
- Usa TMemoryStream para copiar o mover datos en memoria
- Usa TFileStream para tener la capacidad de guardar en disco y recuperar de él.

Y ya solo queda indicarte cómo moverte dentro de él (seek), para leer (read) y escribir en él (como supones: write), también tienes la forma de saber el tamaño (ahora no recuerdo ainsss)

Lo del scroll vertical.... bueno, algunos programas lo que hacen es poner un TScrollbar a la derecha del TMemo y parace que es sólo un componente. Ahora ese Scroll puedes controlarlo a voluntad:
- Sabiendo el tamaño del Stream, configuras sus propiedades Max y Min
- Leyendo la posición del scroll, sabes en qué parte se está desplazando el usuario.
- Controlando sus eventos, puedes ordenar la carga de esa parte (usando seek y read del stream).

Saludos

Gracias a todos por vuestra ayuda.

Gracias Lepe por la información.

Un saludo.