Versão e compilação: SQL Server 2005 SP4 (9.0.5000)
Como uma espécie de isenção de responsabilidade, estou fazendo esta pergunta para gerar alguma discussão e/ou debate sobre o assunto. Não sei se realmente existe uma resposta correta, ou se a resposta correta é um grande e gordo "Depende". Como tal, serei muito lento em aceitar uma resposta, a menos que sejam apresentadas evidências definitivas que não possam ser contestadas pela visão oposta.
O problema lida com o OBJECTPROPERTY CnstIsNotTrusted e o OBJECTPROPERTY CnstIsNotRepl e como eles se relacionam. A propriedade CnstIsNotTrusted é controlada com WITH CHECK|NOCHECK ao adicionar ou verificar uma restrição. A propriedade CnstIsNotTrusted significa que a restrição foi habilitada sem verificar as linhas existentes; portanto, a restrição pode não ser verdadeira para todas as linhas. Quando true, a restrição não pode ser usada para otimização de consulta. Por exemplo, eu tenho uma tabela Person com uma restrição de verificação em LastName garantindo LastName LIKE 'Mc%'. Se CnstIsNotTrusted = 1, se eu pesquisar LastName = 'Smith', o plano de consulta ainda precisará verificar/buscar o índice. Se CnstIsNotTrusted = 0, o plano de execução nem tocará na tabela. Isso foi comprovado aqui:
https://sqlserverfast.com/blog/hugo/2007/03/can-you-trust-your-constraints/
O OBJECTPROPERTY CnstIsNotRepl (NOT FOR REPLICATION em DDL) impõe que a restrição não será verificada durante as sincronizações de replicação. Mais precisamente, o lado do editor será verificado, mas o lado do assinante não. Isso garante que a mesma restrição não seja verificada mais de uma vez. No entanto, usar NOT FOR REPLICATION tornará sua restrição não confiável.
Minha pergunta é, vale a pena os ciclos extras de CPU não usar NOT FOR REPLICATION, para às vezes receber um plano de execução mais eficiente?
