APPLETS: xml o vector

[marmotilla]

hola, me dispongo a crear un applet que trabaje con cierta informacion de una base de datos. Los registros que tengo que mostrar son miles y no se si la mejor forma de traerlos al cliente es:

- guardandolos primero en un XML y leyendolos cada vez que quiera hacer busquedas en ellos

- guardandolos en un vector y hacer las búsquedas sobre ese vector

quiero que las busquedas sean rapidas pero también que la aplicación sea eficiente, asi que no se si tener un vector de miles de registros es más eficiente que escribir y leer un archivo XML (por no hablar de la falta de seguridad que creo que supone tener todos los datos guardados en un archivo en el servidor)

si alguien pudiera ayudarme se lo agradecería :)

[HackmanC]

Hola,

¿Vas a mostrar miles de registros en pantalla?
¿Habrá alguien que vaya a revisarlos uno a uno?

¿No sería mas adecuado hacer un formulario de búsqueda, donde el usuario pueda seleccionar solamente un registro y traer de la base de datos solamente ese, por medio de una selección de campos con meta-caracteres?

Es decir, con 10,000 registros de 1 Kb por dupla, te consumiría más de 9.8 Mb. de RAM, y un costo de 4 ó 5 minutos de transferencia por redes a 256 Kbps. sin incluir las etiquetas XML.

¿No sería más adecuado hacer las consultas directamente a la base de datos? Casi podría asegurar que un SELECT en el DBMS va a ser mucho más rápido en una base de datos bien indexada, que un .find() en cualquier lenguaje de programación.

Pero puedo estar equivocado,
Saludos,

[marmotilla]

Si, tengo búsquedas directas desde la página html a la BD, pero la idea de los registros es listar parte de ellos (segun lo que se quiera buscar) y una vez listada una parte elegir los datos de un registro concreto. El caso es que quería que hiciera un listado de elementos rápido, porque buscar en la BD es muy costoso, como has dicho.

Ya veo que la cantidad de registros con los que tengo que trabajar es un problema en ambos casos.

Gracias!

[HackmanC]

Hola,

Creo que si se pasa de 100 registro es inútil, casi nadie va a navegar más de 100 registros en busca de 1 en particular, menos en una aplicación de punto de venta, inventarios, etc. Por eso te mencionaba, buscar por nombre 'pedro perez*' donde debería devolver 4 o 5, o código 4156* igualmente un par de duplas.

Un ejemplo, 100,000 productos, en un servidor bueno así como una DBMS respetable, una búsqueda por texto te toma menos de una fracción de segundo, en RAM la misma búsqueda desde cualquier lenguaje de programación te puede tomar muchos minutos.

En otras palabras, es más costoso hacerlo desde un archivo local o remoto en XML y/o directamente desde el RAM, que hacer una consulta a la DB, pero esa consulta debe ser suficientemente especifica, para que no te devuelva los mismos 100,000 productos.

Si tienes más de 100 duplas en memoria, deberías de reconsiderar el diseño de tu aplicación, en mi poca experiencia en programación de sistemas administrativos, he visto que nunca, un empleado se va a tomar la molestia en buscar uno a uno dentro de cien productos, (a más que tenga tanto tiempo disponible para no hacer otra cosa más que eso).

Saludos,

[marmotilla]

Vale, muchas gracias HackmanC :)