To clarify the problem, you want clients to receive updates when certain data changes in the database.
SQL Server 2005 and 2008 do support the concept of notifying clients when data changes (MSDN). However, this SO question would seem to indicate that this feature is not present in SQL azure at this time. This means that you have a few options:
Poll the database itself
- This option lets you keep costs down, as you already have everything you need. The disadvantage of course is that you are doing (potentially large) queries at a relatively frequent interval. With enough clients this will drastically slow down due to the load involved. It could also prove costly if you have a price/transfer scheme.
Wrap a service around the database and talk to that
- This could be used with polling, but is even better when using a push technology (like sockets or WebSockets). This of course has additional upfront costs, but allows you to control what updates are received and when. Ideally, this service would keep a copy of the database in-memory that it used to service client requests, while updating the actual DB on its own. This keeps queries to the database (which are slow) at a minimum.
Only you know the right answer for this, but I would go with the second. It will be more performant, scale better, and prove more extensible when you need functionality that goes beyond simple queries.