SQL Server na prática

Chaves estrangeiras no SQL Server: índices e confiança

Identifique chaves estrangeiras desabilitadas ou não confiáveis e recupere a integridade sem confundir validação histórica com fiscalização de novas escritas.

Uma carga termina depois que chaves estrangeiras foram temporariamente desabilitadas. A aplicação volta e as novas inserções parecem verificadas. Meses depois, excluir um cliente demora e relatórios encontram pedidos sem cliente. Duas questões foram misturadas: validar os dados existentes e pesquisar eficientemente as linhas relacionadas.

Uma chave estrangeira não cria automaticamente um índice nas colunas da tabela filha. A chave primária ou única do pai oferece uma referência válida, mas o SQL Server ainda pode precisar procurar filhos ao atualizar ou excluir o pai. Uma pequena operação pode acabar percorrendo uma tabela enorme.

Separar habilitação e confiança

Execute a consulta no banco afetado. A visibilidade dos metadados depende das permissões. Uma lista vazia obtida por uma identidade restrita não demonstra que todas as relações estão corretas.

SELECT
    OBJECT_SCHEMA_NAME(fk.parent_object_id) AS ChildSchema,
    OBJECT_NAME(fk.parent_object_id) AS ChildTable,
    fk.name,
    fk.is_disabled,
    fk.is_not_trusted,
    fk.delete_referential_action_desc
FROM sys.foreign_keys AS fk
WHERE fk.is_disabled = 1 OR fk.is_not_trusted = 1;

Uma restrição habilitada pode continuar não confiável. Habilitá-la sem conferir as linhas antigas pode proteger alterações futuras e deixar violações históricas. O otimizador não pode usar as mesmas premissas de uma relação validada. Uma nova inserção correta, portanto, não comprova a integridade do conjunto inteiro.

Uma restrição desabilitada representa outra condição: as escritas futuras também ficam sem essa fiscalização. Registre a causa e o que foi alterado durante esse período. Se a aplicação continuou funcionando, validar apenas o lote original deixa de fora mudanças posteriores.

Corrigir antes de certificar

As próximas instruções são um padrão para adaptar às tabelas de prática existentes dbo.Orders e dbo.Customers. Confirme nomes e relacionamento reais. O anti-join localiza identificadores não nulos de clientes sem pai; não determina se pedidos devem ser apagados, corrigidos ou associados a um cliente recuperado.

SELECT o.CustomerId, COUNT_BIG(*) AS OrphanRows
FROM dbo.Orders AS o
LEFT JOIN dbo.Customers AS c ON c.CustomerId=o.CustomerId
WHERE o.CustomerId IS NOT NULL AND c.CustomerId IS NULL
GROUP BY o.CustomerId;

CREATE INDEX IX_Orders_CustomerId
ON dbo.Orders(CustomerId);

ALTER TABLE dbo.Orders
WITH CHECK CHECK CONSTRAINT FK_Orders_Customers;

Os dois CHECK têm funções diferentes. WITH CHECK valida os registros existentes; CHECK CONSTRAINT habilita a restrição. A validação pode ler muitos dados e obter bloqueios. Estime esse trabalho e confira depois is_disabled e is_not_trusted. O estado real do catálogo é mais confiável que a lembrança de ter habilitado a regra.

Uma chave filha anulável pode usar NULL para representar ausência de relação. Nem toda linha nula é órfã. Chaves compostas exigem comparação de todas as colunas envolvidas e consideração da nulabilidade. Uma correção usando nomes descritivos no lugar da chave declarada pode criar relacionamentos errados.

Avaliar os dois sentidos do acesso

Antes de adicionar o índice mostrado, examine os existentes. Um índice composto iniciado por CustomerId pode atender às verificações e consultas. Colocar CustomerId depois de uma chave independente geralmente não oferece o mesmo acesso. Analise planos de exclusão do pai e das consultas importantes da tabela filha.

Indexar todas as chaves estrangeiras sem considerar a carga aumenta espaço e escritas. Entretanto, dispensar um índice porque a aplicação quase não usa joins pode ignorar verificações de exclusão e cascatas. Meça os dois sentidos. Grandes cascatas ainda geram log e bloqueios com índices adequados, pois as modificações reais continuam necessárias.

Um teste de encerramento deve inserir um filho válido, tentar outro inválido em uma transação controlada e exercitar uma alteração representativa do pai em ambiente seguro. Confirme que a identidade da aplicação recebe e trata o erro esperado. Confiança da restrição, integridade e desempenho precisam de evidências próprias.

O processo de importação deve registrar o resultado da validação e parar diante de falha. Um passo genérico chamado “habilitar restrições” pode esconder durante meses que os registros antigos nunca foram conferidos. Essa distinção evita acumular exceções difíceis de corrigir depois.

Referências técnicas: Microsoft Learn: Foreign keys · Microsoft Learn: Constraint trust.

Pergunte sobre este artigo

Tem alguma dúvida sobre este tema?

Conte o que você está avaliando ou onde encontrou dificuldades. Responderemos com uma recomendação prática.

Inquiries are not enabled in this preview.

Fazer uma pergunta sobre este artigo