SqlDependency will only notify you that a change occurred, and you'll have to re-read the entire table. It works well with a low rate of notifications. At a high rate, you have to consider that notifications have a significant cost. See The Mysterious Notification for more details how SqlDependency works. As you cans see, there is significant cost:
- setting up the notification (writing in sys.dm_qn_subscriptions and in SSB system tables)
- firing the notification (writing sys.dm_qn_subscriptions)
- delivering the notification (writes in SSB system tables, target queue)
- receiving the notification (writes in target queue, SSB system tables)
That's quite a few writes, the cost will add up quickly if you get notified constantly.
But the real question is how exactly do you want to react in the application to a constant rate of change? what do you want to know, that something changed? well, you know, it always does, anytime the application needs the data it better read the latest state, because it certainly changed. Polling does not make sense either. Sounds like what you really want is either change tracking or, more likely, a custom based queue of changes fed by the change originators.