ALTER TABLE CHECK CONSTRAINT

25

No Pesquisador de objetos do SQL Server, ao selecionar e criar scripts de uma restrição de chave estrangeira, o código a seguir é gerado.

     USE [MyTestDatabase]
     GO

     ALTER TABLE [dbo].[T2] WITH NOCHECK ADD CONSTRAINT [FK_T2_T1] FOREIGN KEY([T1ID])
     REFERENCES [dbo].[T1] ([T1ID])
     GO

     ALTER TABLE [dbo].[T2] CHECK CONSTRAINT [FK_T2_T1]
     GO

Qual é o objetivo da última declaração "ALTER TABLE CHECK CONSTRAINT"? Não parece importar se é executado ou não. Ele não falha nos dados incorretos existentes, nem altera que a restrição será aplicada a novos dados.

Obrigado!

sql-server-2008

— Delux
fonte

23

Ele garante que a restrição seja ativada após a criação. Sua ALTER TABLEdeclaração inclui WITH NOCHECKqual é a parte que diz para não verificar se há dados incorretos existentes durante a criação da restrição.

Conforme gravado, os dados existentes não serão verificados em relação à restrição, devido ao WITH NOCHECKda primeira instrução. A emissão da segunda instrução permitirá a verificação contra a restrição para quaisquer alterações futuras na tabela que são cobertas pela restrição, até o ponto em que uma ALTER TABLE [dbo].[T2] NOCHECK CONSTRAINT [FK_T2_T1]é emitida.

As instruções, como estão escritas, estão basicamente dizendo "Crie essa restrição de chave estrangeira, mas não a verifique nos dados existentes. Torne-o ativo para quaisquer alterações futuras nos dados".

— squillman
fonte

Na verdade, verifiquei que, não faz diferença se houver dados ruins, a primeira ou a segunda linha não falhará. Para fazer com uma falha, eles teriam que ficar assim:

— Delux

2

ALTER TABLE [dbo]. [T2] COM RESTRIÇÃO DE VERIFICAÇÃO DE VERIFICAÇÃO [FK_T2_T1]

— Delux

Direita. Mas você verá que falhará depois disso, quando em algum momento tentar executar um INSERT ou UPDATE que viole a restrição. Nenhuma delas falhará se existirem dados incorretos no momento em que essas 2 instruções forem executadas.

— squillman

7

Sua primeira instrução cria uma restrição desabilitada. Ele precisa estar ativado e possivelmente confiável. A seguinte sintaxe estranha garantirá que sua restrição esteja ativada e confiável:

ALTER TABLE YourTable
      WITH CHECK CHECK CONSTRAINT YourConstraint;

Existe uma publicação muito boa de Hugo Kornelis no blog que explica em detalhes: Você pode confiar em suas restrições

— AK
fonte