ALTER TABLE CHECK CONSTRAINT

25

SQL Serverのオブジェクトエクスプローラーから、外部キー制約を選択してスクリプトを作成すると、次のコードが生成されます。

     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

最後のステートメント「ALTER TABLE CHECK CONSTRAINT」の目的は何ですか？実行されるかどうかは問題ではないようです。既存の不良データでは失敗せず、新しいデータに制約が適用されることも変わりません。

ありがとう！

sql-server-2008

— デラックス
ソース

23

これにより、制約が作成された後に有効になります。あなたALTER TABLEの文は、WITH NOCHECK制約の作成時に既存の不良データをチェックしないと言う作品です。

記述されているように、既存のデータはWITH NOCHECK最初のステートメントのために制約に対してチェックされません。2番目のステートメントを発行すると、制約の対象となるテーブルへの将来の変更について、制約が発行されるまで、制約に対するチェックが有効になりますALTER TABLE [dbo].[T2] NOCHECK CONSTRAINT [FK_T2_T1]。

記述されているように、ステートメントは基本的に「この外部キー制約を作成しますが、既存のデータに対してチェックしないでください。データに対する今後の変更に対してアクティブにします。」

— スクイルマン
ソース

実際に確認したところ、不良データがあったとしても違いはありません。1行目または2行目は失敗しません。1つの失敗で成功するには、次のようにする必要があります

— 。– Delux

2

ALTER TABLE [dbo]。[T2] WITH CHECK CHECK CONSTRAINT [FK_T2_T1]

— デラックス

右。しかし、ある時点で制約に違反するINSERTまたはUPDATEを実行しようとすると、失敗することがわかります。これらの2つのステートメントの実行時に不良データが存在する場合、どちらも失敗しません。

— squillman

7

最初のステートメントは、無効な制約を作成します。有効にし、場合によっては信頼する必要があります。次の奇妙な構文は、制約が有効で信頼できることを確認します。

ALTER TABLE YourTable
      WITH CHECK CHECK CONSTRAINT YourConstraint;

Hugo Kornelisによる非常に優れたブログ投稿があり、これについて詳しく説明しています。制約を信頼できますか

— AK
ソース