title: Using SqlDependency vs. periodic polling of a table (performance impact)
body: <p>In the beginning of our app's development, we were using SqlDependency quite heavily to cache DB results until the notifications told our app to grab a fresh copy.</p>
  
  <p>During testing, we've noticed that the SQL DB's performance was getting hammered by the SqlDependency notification service. We scaled back the number of tables that we were using SqlDependency and noticed a large gain in performance. So, we thought we were just over using it and we moved on. We are down to only a few tables now.</p>
  
  <p>Later, we discovered that we couldn't scale back the security access level for the username that will establish the dependency. We could have more than one connection string for each DB (one for dependency and one for the rest of the app), but with multiple DBs and DB mirroring, this is a pain (from SQL DB admin point of view and app development).</p>
  
  <p>At this point, we are just thinking about moving away from SqlDependency altogether based on the following logic:</p>
  
  <ol>
  <li>We don't need "instant" notification that the data has changed. If we knew within 1 second, that would be fast enough.</li>
  <li>With some slight refactoring, we could get it down to just 1 table and poll that table once a second.</li>
  </ol>
  
  <p>Does anyone see a flaw in this logic? </p>
  
  <p>Would polling one table once a second cause more or less load on the DB than SqlDependency?</p>
  
  <p>Has anyone had similar performance issue with SqlDependency?</p>