Ayuda con arquitectura

Hola,
Lo que yo haria es guardar la fecha o un timespan o un "numero de
version" que se vaya actualizando cuando se cargue nueva informacion.
El cliente deberia saber que version mostro por ultima vez y
actualizar la informacion de acuerdo a las 2 versiones (la de la base
de datos y la ultima que el bajo).
Otra forma seria que cada registro con informacion tenga la fecha, y
cuando vos consultas simplemente haces un select * from info where
fecha >= @fecha_ultima_actualizacion de nuevo, la fecha de ultima
actualizacion la deberia guardar el cliente localmente para saber que
informacion tiene y cual no...
La 3er posibilidad que se me ocurre es usar los eventos de SqlServer
2005. Si bien es mucho mas simple, rapido y te evita tener que estar
preguntando cada 5 minutos, tenes el problema que te quedas "pegado"
al motor de base de datos.

Creo que las opciones estan ordenadas de forma tal que la primera es
la que aplica en mayor parte de casos y la ultima es la que mas
restricciones impone. La 2da puede ser una buena opcion, pero no se si
queres/podes agregar esa informacion en la base de datos...

Lo de los eventos de SQL Server 2005 no creo que haya problemas, pero
tendrias que tener en cuenta que no te va a convenir mucho si cada
terminal actualiza los datos 10 veces por segundo, por ejemplo...

Otra solucion que se me esta ocurriendo es manejar eventos en la
aplicacion del cliente que sean enviados (desde las terminales)
mediante Message Queue o algo similar, pero dudo que tenga sentido
algo asi en tu caso... Es simplemente una idea que puede servir para
generar un evento en el cliente y decirle "che! hay info nueva! :)"

Con respecto a lo del count(*), no me gusta demasiado... creo que va a
hacer las cosas dificiles de entender, pero no significa que no vaya a
funcionar, incluso es mas facil de hacerlo.. Pero fijate si en un
futuro no vas a hacer un update en vez de un insert, ya que esto
arruinaria las cosas... es por eso que no me gusta mucho, es
informacion parcial sobre si hay nueva informacion...
En caso de que sea una aplicacion de log solamente, te pueden pedir en
algun momento que dejes solo lo de los ultimos 2 años para disminuir
el tamaño, y en ese caso tambien se te va a romper la aplicacion del
cliente.
Se entiende porque no me gusta mucho el count(*) ??

Saludos!,
Diego

Gracias Diego... te pregunto lo de SystemMessage.. esto seria un CallCenter,
no lo vez bueno la idea que el demonio ni bien recibe informacion aparte de
grabar envie un mensaje diciendo hay algo nuevo?? Y que los clientes esten
solo escuchando??

Por otro lado me gustaria que me cuenten aquellos que trabajaron con esto
que tal les resulto asi ya lo se para una proxima vez.

Lo que quiero es alguna forma que los clientes esten escuchando ya sea por
algun puerto, leyendo la DB, etc, y que ni bien reciban algo de info
empiecen a trabajar.


"Diego Jancic" escribió en el mensaje
news:
Hola,
Lo que yo haria es guardar la fecha o un timespan o un "numero de
version" que se vaya actualizando cuando se cargue nueva informacion.
El cliente deberia saber que version mostro por ultima vez y
actualizar la informacion de acuerdo a las 2 versiones (la de la base
de datos y la ultima que el bajo).
Otra forma seria que cada registro con informacion tenga la fecha, y
cuando vos consultas simplemente haces un select * from info where
fecha >= @fecha_ultima_actualizacion de nuevo, la fecha de ultima
actualizacion la deberia guardar el cliente localmente para saber que
informacion tiene y cual no...
La 3er posibilidad que se me ocurre es usar los eventos de SqlServer
2005. Si bien es mucho mas simple, rapido y te evita tener que estar
preguntando cada 5 minutos, tenes el problema que te quedas "pegado"
al motor de base de datos.

Creo que las opciones estan ordenadas de forma tal que la primera es
la que aplica en mayor parte de casos y la ultima es la que mas
restricciones impone. La 2da puede ser una buena opcion, pero no se si
queres/podes agregar esa informacion en la base de datos...

Lo de los eventos de SQL Server 2005 no creo que haya problemas, pero
tendrias que tener en cuenta que no te va a convenir mucho si cada
terminal actualiza los datos 10 veces por segundo, por ejemplo...

Otra solucion que se me esta ocurriendo es manejar eventos en la
aplicacion del cliente que sean enviados (desde las terminales)
mediante Message Queue o algo similar, pero dudo que tenga sentido
algo asi en tu caso... Es simplemente una idea que puede servir para
generar un evento en el cliente y decirle "che! hay info nueva! :)"

Con respecto a lo del count(*), no me gusta demasiado... creo que va a
hacer las cosas dificiles de entender, pero no significa que no vaya a
funcionar, incluso es mas facil de hacerlo.. Pero fijate si en un
futuro no vas a hacer un update en vez de un insert, ya que esto
arruinaria las cosas... es por eso que no me gusta mucho, es
informacion parcial sobre si hay nueva informacion...
En caso de que sea una aplicacion de log solamente, te pueden pedir en
algun momento que dejes solo lo de los ultimos 2 años para disminuir
el tamaño, y en ese caso tambien se te va a romper la aplicacion del
cliente.
Se entiende porque no me gusta mucho el count(*) ??

Saludos!,
Diego

Hola,
Nunca use SystemMessages, pero creo que vas a necesitar algo del
estilo... si lo que tenes que hacer es asignarle un nueva llamada a un
cliente, lo mejor seria que le informes en el momento a ese cliente
solamente.
Creo que si contas mas especificamente que informacion es la que tenes
que guardar y cual es el objetivo del cliente escuchando te vamos a
poder ayudar un poco mejor...

Ademas no entendi si hay un solo cliente o muchos leyendo la
informacion desde la base de datos (entendi cosas diferentes en tus 2
posts..)

Saludos,
Diego

"Cesar Gazzo" wrote in message
news:

- De que forma podria hacer para que los clientes sepan que hay nuevos
registros en la db?

Una seria que cada N segundos hagan un Count(*) y si hay nuevos registros
los levanten.

Sería preferible meter un trigger en las tablas "interesantes" de forma
que cuando haya un cambio en la tabla el trigger grabe un registro de
control sobre una tabla auxiliar muy pequeña, indicando la existencia de
dicho cambio. Los clientes harían el polling leyendo solo el registro de
cambios sobre la tabla auxiliar, que sería mucho más rápido que el Count(*)
sobre la grande, además de disminuir la contención sobre esta última.

Si no quieres "cargar" el servidor con operaciones de polling, y es un
SQL Server 2005, una alternativa sería que el anteriormente mencionado
trigger estuviera escrito en .Net, y desde dentro del trigger utilizaras
cualquier tipo de mecanismo de comunicación inter-procesos (por ejemplo
colas de mensajes o eventos de Remoting o eventos débilmente acoplados de
Component Services) para notificar a las estaciones la existencia de
cambios.

On Thu, 17 May 2007 22:47:06 -0300, "Cesar Gazzo"
wrote:

- De que forma podria hacer para que los clientes sepan que hay nuevos
registros en la db?

También puedes mirar SQL Server Service Broker.


Saludos