Re: a vueltas con la transferencia de datos

Gracias por tu recomendación, sé que una forma de arreglar los
posibles problemas que tenga será verificar el correcto funcionamiento
de los querys.
Pero el problema que planteo es otro, imaginemos que tengo en un
cliente una tabla de datos ya obtenido de nuestra base de datos. A la
hora de por ejemplo ordenar los datos por fecha, u otro campo, que
seria mejor :
- mandar al servidor para que los ordene el. ( creo que no es buena opcion ).
- manejar los datos obtenidos por el servidor en el cliente. esta es
la cuestión como lo manejo con XML por ejemplo, y de que forma lo
hago. la verdad es que ando algo pez a la hora de abordar y crear
paginas web dinamicas en contacto con postgresql y con los datos en
xml. Si me indicaras por donde empezar te lo agradeceria.

Gracias por tu tiempo

El 3/10/05, Alvaro Herrera<alvherre(at)alvh(dot)no-ip(dot)org> escribió:
> On Sun, Oct 02, 2005 at 10:13:29PM +0200, Rafael De_Linares wrote:
>
> > La cuestiön a plantearos es algo que me va rondando la cabeza y que
> > seguramente con el paso del tiempo tendrë que abordar de una forma u
> > otra; y es la transferencia en la cantidad de datos; no se si algunos
> > os ha pasado pero al realizar un query al servidor y mostralo en el
> > cliente; estos datos resultan ya pesados a la hora tanto de
> > transmitirlo como de presentarlo en el cliente; para filtrarlos;
> > ordenarlos ; etcc: en el cliente:
>
> Si estas filtrando y ordenando en el cliente, estas incurriendo en
> desperdicio de recursos. Usa clausulas WHERE, HAVING y ORDER BY
> apropiadamente, y le vas a dar mucho menos trabajo al cliente y a la
> red. Ademas, con mucha probabilidad el servidor puede hacer el trabajo
> de ordenamiento mas eficientemente.
>
>
> > Me ronda dos varias cosas : 1) utilizar otro lenguaje de programación
> > tipo java, servlets
>
> Algoritmos malos se pueden escribir en cualquier lenguaje. Maneras
> buenas de hacer las cosas, tambien.
>
> > 2) algo he leido sobre la capacdad de php a la
> > hora de transmitr información comprimida y por ultimo xml,
> > Esta sin duda es la opción que mas me atrae, que pensais sobre ello.
>
> XML es una solucion en busca de un problema. Lo he visto usado en
> muchos problemas para los que no era la solucion correcta. Te
> recomiendo que no pienses en ello a menos que realmente te parezca que
> sea la unica forma de resolver un problema (no es el caso que planteas).
>
> --
> Alvaro Herrera Architect, http://www.EnterpriseDB.com
> "The first of April is the day we remember what we are
> the other 364 days of the year" (Mark Twain)
>