Planejando notificações
Para usar notificações de consulta de forma eficaz, você deve considerar se seu aplicativo pode se beneficiar das notificações de consulta, se as consultas usadas pelo seu aplicativo dão suporte a notificações, e a estratégia a ser usada pelo aplicativo para inscrever e receber notificações.
As notificações de consulta oferecem um modo prático de reduzir viagens de ida e volta ao banco de dados se os dados da consulta forem alterados relativamente com pouca freqüência; se o aplicativo não exigir uma atualização instantânea das alterações de dados e se a consulta atender os requisitos e as restrições descritas em Criando uma consulta para notificação. Muitos aplicativos baseados na Web atendem esses critérios, e esses aplicativos podem tirar proveito das notificações de consulta.
Nem todo cenário se beneficia das notificações de consulta. As notificações de consulta são úteis nas situações em que um aplicativo lê dados do banco de dados com freqüência, mas em que as atualizações de dados são relativamente pouco freqüentes. Por exemplo, um aplicativo de catálogo online é exibido com mais freqüência do que as atualizações do catálogo. Para um carrinho de compras online, porém, o conteúdo de um particular pode ser atualizado com bastante freqüência, de modo que as notificações de consulta são menos vantajosas.
As notificações de consulta são mais eficazes quando um aplicativo emite consultas que compartilham uma estrutura comum e só variam nos valores dos parâmetros. Por exemplo:
SELECT ProductNumber, Name FROM Production.Product WHERE ListPrice < 300
SELECT ProductNumber, Name FROM Production.Product WHERE ListPrice < 500
Nesse caso, as assinaturas de notificação de consulta de ambas as notificações compartilham do mesmo modelo interno, requerendo menos sobrecarga no SQL Server que duas notificações com estruturas de consulta diferentes. Observe-se, no entanto, que os parâmetros das consultas são preservados. Embora as consultas compartilhem um modelo, adicionar um item com uma ListPrice de 350 origina uma notificação na segunda consulta, mas não na primeira.
Quando as notificações de consulta estiverem ativas em uma tabela, as atualizações da tabela serão mais dispendiosas. O Mecanismo de Banco de Dados executa trabalho extra para verificar as assinaturas e, se necessário, gerar notificações. Reutilizar modelos internos ajuda a minimizar a sobrecarga por assinatura. Por isso, você só deve usar notificações de consulta em aplicativos que enviem consultas de estruturas semelhantes. Um aplicativo que envia consultas com estruturas diferentes não deve usar notificações de consulta.
Por exemplo, um aplicativo que mostra itens de catálogo em determinada faixa de preços envia consultas com a mesma estrutura. Nesse caso, o Mecanismo de Banco de Dados pode utilizar novamente o modelo interno de cada consulta, e as notificações de consulta podem melhorar o desempenho. No entanto, um aplicativo que propicia relatórios ad hoc envia consultas com estrutura variável. Nesse caso, o aplicativo não deve usar notificações de consulta.
O Mecanismo de Banco de Dados mantém um modelo interno, contanto que seja usado por pelo menos uma assinatura registrada. O Mecanismo de Banco de Dados limita o número de modelos internos diferentes em uma tabela específica. Quando esse limite é atingido, o Mecanismo de Banco de Dados não registra assinaturas que possam causar a criação de um novo modelo. Em vez disso, o Mecanismo de Banco de Dados gera imediatamente uma mensagem de assinatura indicando que ela não pôde ser registrada.