>I have an application which is being updated with prices from the
>financial markets.
>
>I'd like the client application which retrieves this data from the
>database not to have to do repeated SELECTs to determine when the data
>changes, but to somehow have a way to be advised that a table has
>changed.
>
>I think triggers can be used to perform calculations/functions on the data
>in the database (as inserts/updates take place) which would solve most of
>my problems, but I still need the "client" to know when the data changes.
>If I want to cope with "real-time" (sub 1 second) updates for a number of
>clients frequent SELECTS will presumably cause a severe load on the
>server, which I'd prefer to avoid.
A lot of the stuff I've seen uses some sort of push technology. This can be
as simple as doing a select to get the rows that have changed, then push the
data out to the clients. Easiest way, if you have TCP/IP, is to have a
socket listening on the client - when the data changes, the server opens a
socket to the client, pushed out the data, then closes the socket. Of
course, you have to contend with clients having to register their IP address
with you and dealing with clients that go away and don't de-register. You
get the idea. :)
