Problema al usar un WebService

Bien podria ser como dices Jesus, es mas, porque no una marca de tiempo en
todos los registros de cuando los insertaron (porque afirma que no hay
updates ni deletes) y enviar como parametro la fecha y hora exacta de la
ultima actualizacion para saber cuales se han agregado despues. Esto me
suena mucho al IssueVision.

"Jesús López" escribió en el mensaje
news:
Mostrar la cita

Yo lo que haría sería tener una copia actualizada de los datos en los
clientes en una base de datos de SQLite y haría las consultas sobre la
base de datos local en vez de "molestar" al servidor cada vez.

Implementar esta copia actualizada es sencillo, teniendo en cuenta que en
la tabla las únicas modificaciones son las inserciones. Sería cuestión de
tener un método en el servicio web como este:

Public Function ObtenerAccesos( IdUltimaSincronización As Integer ) As
Dataset

Básicamente este método devolvería los accesos producidos desde la última
sincronización. Una select similar a esta:

SELECT FROM LaTabla WHERE Id > @UltimaSincronización

Todo esto suponiendo que LaTabla tiene un Id autonumérico.

Las aplicaciones cliente podrían sincronizarse cada vez que arrancan o
cada vez que se hace una consulta sobre los accesos. Lo que tienen que
hacer es guardar la última sincronización, es decir, el ID mayor e
insertar los registros en la base de datos local.

SQLite es un sistema de gestión de base de datos "embedded" y "open
source" que no requiere ninguna configuración. Con solo copiar el archivo
System.Data.SQLite.dll en el directorio de la aplicación ya está. Además
es tremendamente eficiente en cargas masivas de datos y en lecturas y
admite encriptación basada en contraseñas. Aquí puedes encontrar el
proveedor de datos nativo para ADO.NET 2.0:

http://sqlite.phxsoftware.com/

Saludos:

Jesús López


"Alberto Poblacion"
escribió en el mensaje news:
Mostrar la cita

"Asier" wrote in message
news:%
Mostrar la cita

Antes de nada, gracias por vuestra ayuda. La pantalla recoge accesos
a
un edificio y claro, si consultan todos los accesos de un año, hay
bastantes. Os podeis imaginar que la tablña está continuamente
recibiendo
nuevos registros, eso si, sobre esa tabla no hay nunca ni deletes ni
updates, solo insert (muy frecuentes) y select (menos frecuentes).
Tienen
filtros para seleccionar por fechas, etc. La select esta bastante
optimizada
pero el equipo que tengo de pruebas tiene todo, base de datos, servicio
web
y aplicación winforms, así que no puede ser nada de la red

Aunque no haya red, mover 150 megabytes a través del stack de IP del
ordenador sigue siendo costoso. especialmente si además tienen que irse
procesando sobre la marcha (la CPU tiene que codificar todos esos datos
en XML y luego volver a decodificar el XML reconstruyendo los datos.
Aparte de eso, el ordenador tendrá varias copias en memoria (el
dataset (con los strings en Unicode), más el texto en xml, más la copia
de ese xml recibida por el programa cliente, más el resultado de
decodificar ese xml en el dataset del lado cliente. Por no hablar del
caché de páginas del servidor SQL, y, si el dataset está vinculado a un
control en el lado cliente, el espacio ocupado por la representación de
los datos en ese control. Total, que a lo mejor estás manejando un
gigabyte de datos en la memoria de ese ordenador, lo cual posiblemente va
a ocasionar una gran cantidad de swapping que también va a enlentecer el
proceso.
En resumen, estoy de acerdo con Jesús en que es preferible cambiar el
diseño de la aplicación; mover semejante volumen de datos a través de una
única llamada a un servicio web va a resultar lento en cualquier caso.

Basarse en la fecha y hora exacta de inserción no creo que sea una buena
idea. Presenta algunos problemillas:

(1) Puede haber más de un registro con la misma fecha y hora insertados por
distintas conexiones. Lo que podría provocar que el cliente se "saltara"
algunos registros.
(2) Un cambio en la fecha y hora del sistema lo echaría todo a perder.
(3) El servidor y el cliente pueden tener horas distintas. Relojes no
sincronizados.


Un autonumérico es mucho más seguro, no hay dos registros con el mismo id y
se insertan en orden estricto. Además son más eficientes al ser más pequeños.

Saludos:

Jesús López



"Eduardo Alvarado Meza" escribió:

Mostrar la cita

Bien podria ser como dices Jesus, es mas, porque no una marca de tiempo en
todos los registros de cuando los insertaron (porque afirma que no hay
updates ni deletes) y enviar como parametro la fecha y hora exacta de la
ultima actualizacion para saber cuales se han agregado despues. Esto me
suena mucho al IssueVision.

"Jesús López" escribió en el mensaje
news:
> Yo lo que haría sería tener una copia actualizada de los datos en los
> clientes en una base de datos de SQLite y haría las consultas sobre la
> base de datos local en vez de "molestar" al servidor cada vez.
>
> Implementar esta copia actualizada es sencillo, teniendo en cuenta que en
> la tabla las únicas modificaciones son las inserciones. Sería cuestión de
> tener un método en el servicio web como este:
>
> Public Function ObtenerAccesos( IdUltimaSincronización As Integer ) As
> Dataset
>
> Básicamente este método devolvería los accesos producidos desde la última
> sincronización. Una select similar a esta:
>
> SELECT FROM LaTabla WHERE Id > @UltimaSincronización
>
> Todo esto suponiendo que LaTabla tiene un Id autonumérico.
>
> Las aplicaciones cliente podrían sincronizarse cada vez que arrancan o
> cada vez que se hace una consulta sobre los accesos. Lo que tienen que
> hacer es guardar la última sincronización, es decir, el ID mayor e
> insertar los registros en la base de datos local.
>
> SQLite es un sistema de gestión de base de datos "embedded" y "open
> source" que no requiere ninguna configuración. Con solo copiar el archivo
> System.Data.SQLite.dll en el directorio de la aplicación ya está. Además
> es tremendamente eficiente en cargas masivas de datos y en lecturas y
> admite encriptación basada en contraseñas. Aquí puedes encontrar el
> proveedor de datos nativo para ADO.NET 2.0:
>
> http://sqlite.phxsoftware.com/
>
> Saludos:
>
> Jesús López
>
>
> "Alberto Poblacion"
> escribió en el mensaje news:
>> "Asier" wrote in message
>> news:%
>>> Antes de nada, gracias por vuestra ayuda. La pantalla recoge accesos
>>> a
>>> un edificio y claro, si consultan todos los accesos de un año, hay
>>> bastantes. Os podeis imaginar que la tablña está continuamente
>>> recibiendo
>>> nuevos registros, eso si, sobre esa tabla no hay nunca ni deletes ni
>>> updates, solo insert (muy frecuentes) y select (menos frecuentes).
>>> Tienen
>>> filtros para seleccionar por fechas, etc. La select esta bastante
>>> optimizada
>>> pero el equipo que tengo de pruebas tiene todo, base de datos, servicio
>>> web
>>> y aplicación winforms, así que no puede ser nada de la red
>>
>> Aunque no haya red, mover 150 megabytes a través del stack de IP del
>> ordenador sigue siendo costoso. especialmente si además tienen que irse
>> procesando sobre la marcha (la CPU tiene que codificar todos esos datos
>> en XML y luego volver a decodificar el XML reconstruyendo los datos.
>> Aparte de eso, el ordenador tendrá varias copias en memoria (el
>> dataset (con los strings en Unicode), más el texto en xml, más la copia
>> de ese xml recibida por el programa cliente, más el resultado de
>> decodificar ese xml en el dataset del lado cliente. Por no hablar del
>> caché de páginas del servidor SQL, y, si el dataset está vinculado a un
>> control en el lado cliente, el espacio ocupado por la representación de
>> los datos en ese control. Total, que a lo mejor estás manejando un
>> gigabyte de datos en la memoria de ese ordenador, lo cual posiblemente va
>> a ocasionar una gran cantidad de swapping que también va a enlentecer el
>> proceso.
>> En resumen, estoy de acerdo con Jesús en que es preferible cambiar el
>> diseño de la aplicación; mover semejante volumen de datos a través de una
>> única llamada a un servicio web va a resultar lento en cualquier caso.
>>
>>
>
>

A como dicen... me fregastes bien duro ;-), tenes toda la razón.