No início do desenvolvimento de nosso aplicativo, estávamos usando bastante o SQLDependency para armazenar em cache os resultados do banco de dados até que as notificações informaram ao nosso aplicativo para obter uma nova cópia.

Durante os testes, notamos que o desempenho do banco de dados sql estava sofrendo com o serviço de notificação sqldependency. Nós reduzimos o número de tabelas que estávamos usando o sqldependency e notamos um grande ganho no desempenho. Então, pensamos que estávamos acabando de usá-lo e seguimos em frente. Estamos reduzidos a apenas algumas tabelas agora.

Mais tarde, descobrimos que não poderíamos reduzir o nível de acesso de segurança para o nome de usuário que estabelecerá a dependência. Poderíamos ter mais de uma cadeia de conexão para cada db (um para dependência e outro para o restante do aplicativo), mas com vários db's e db espelhamento, isso é um problema (do ponto de vista do administrador do sql db e desenvolvimento do aplicativo)

Neste ponto, estamos apenas pensando em sair do SQLDependency completamente com base na seguinte lógica:

Não precisamos de notificação "instantânea" de que os dados foram alterados. Se soubéssemos dentro de um segundo, isso seria rápido o suficiente.Com um pequeno refatoramento, poderíamos reduzi-lo a apenas 1 mesa e pesquisar essa tabela uma vez por segundo.

Alguém vê uma falha nessa lógica?

A pesquisa de uma tabela por segundo causaria mais ou menos carga no banco de dados do que SQLDependency?

Alguém já teve problema de desempenho semelhante com o SQLDependency?