WITH CHECK ADD CONSTRAINT tiếp theo ràng buộc kiểm tra vs Thanh CONSTRAINT

Question

Tôi nhìn vào cơ sở dữ liệu mẫu AdventureWorks cho SQL Server 2008, và tôi thấy trong kịch bản sáng tạo của họ rằng họ có xu hướng sử dụng như sau:

ALTER TABLE [Production].[ProductCostHistory] WITH CHECK ADD 
CONSTRAINT [FK_ProductCostHistory_Product_ProductID] FOREIGN KEY([ProductID]) 
    REFERENCES [Production].[Product] ([ProductID]) 
GO 

ngay sau đó:

ALTER TABLE [Production].[ProductCostHistory] CHECK CONSTRAINT  
[FK_ProductCostHistory_Product_ProductID] 
GO 

tôi thấy điều này cho các phím nước ngoài (như ở đây), ràng buộc duy nhất và thường xuyên CHECK hạn chế; DEFAULT hạn chế sử dụng định dạng thường xuyên Tôi quen thuộc hơn với ví dụ như:

ALTER TABLE [Production].[ProductCostHistory] ADD CONSTRAINT 
[DF_ProductCostHistory_ModifiedDate] DEFAULT (getdate()) FOR [ModifiedDate] 
GO 

sự khác biệt là gì, nếu có, giữa làm nó theo cách đầu tiên so với thứ hai?

Answer 1

Cú pháp đầu tiên là thừa - WITH CHECK là mặc định cho các ràng buộc mới và ràng buộc được bật theo mặc định.

Cú pháp này được tạo bởi phòng quản lý SQL khi tạo tập lệnh sql - tôi giả định đó là một số dư thừa bổ sung, có thể đảm bảo ràng buộc được bật ngay cả khi hành vi ràng buộc mặc định cho bảng được thay đổi.

Answer 2

WITH CHECK thực sự là hành vi mặc định, tuy nhiên, thực tiễn tốt là bao gồm trong mã của bạn.

Hành vi thay thế là tất nhiên để sử dụng WITH NOCHECK, vì vậy bạn nên xác định rõ ràng ý định của mình. Điều này thường được sử dụng khi bạn đang chơi với/sửa đổi/chuyển đổi phân vùng nội tuyến.

Answer 3

Ràng buộc khóa và kiểm tra ngoại khóa có khái niệm là đáng tin cậy hoặc không đáng tin cậy, cũng như được bật và tắt. Xem trang MSDN cho ALTER TABLE để biết chi tiết đầy đủ.

WITH CHECK là mặc định để thêm khóa ngoại và kiểm tra ràng buộc mới, WITH NOCHECK là mặc định cho bật lại khóa và khóa kiểm soát bị khóa. Điều quan trọng là phải nhận thức được sự khác biệt.

Có nói rằng, bất kỳ câu lệnh rõ ràng dự phòng nào được tạo ra bởi các tiện ích chỉ đơn giản là có an toàn và/hoặc dễ dàng mã hóa. Đừng lo lắng về chúng.

Answer 4

WITH NOCHECK cũng được sử dụng khi có dữ liệu hiện có trong bảng không tuân theo ràng buộc như được xác định và bạn không muốn nó chạy afoul ràng buộc mới mà bạn đang triển khai ...

Answer 5

để chứng minh cách này works--

CREATE TABLE T1 (ID INT NOT NULL, SomeVal CHAR(1)); 
ALTER TABLE T1 ADD CONSTRAINT [PK_ID] PRIMARY KEY CLUSTERED (ID); 

CREATE TABLE T2 (FKID INT, SomeOtherVal CHAR(2)); 

INSERT T1 (ID, SomeVal) SELECT 1, 'A'; 
INSERT T1 (ID, SomeVal) SELECT 2, 'B'; 

INSERT T2 (FKID, SomeOtherVal) SELECT 1, 'A1'; 
INSERT T2 (FKID, SomeOtherVal) SELECT 1, 'A2'; 
INSERT T2 (FKID, SomeOtherVal) SELECT 2, 'B1'; 
INSERT T2 (FKID, SomeOtherVal) SELECT 2, 'B2'; 
INSERT T2 (FKID, SomeOtherVal) SELECT 3, 'C1'; --orphan 
INSERT T2 (FKID, SomeOtherVal) SELECT 3, 'C2'; --orphan 

--Add the FK CONSTRAINT will fail because of existing orphaned records 
ALTER TABLE T2 ADD CONSTRAINT FK_T2_T1 FOREIGN KEY (FKID) REFERENCES T1 (ID); --fails 

--Same as ADD above, but explicitly states the intent to CHECK the FK values before creating the CONSTRAINT 
ALTER TABLE T2 WITH CHECK ADD CONSTRAINT FK_T2_T1 FOREIGN KEY (FKID) REFERENCES T1 (ID); --fails 

--Add the CONSTRAINT without checking existing values 
ALTER TABLE T2 WITH NOCHECK ADD CONSTRAINT FK_T2_T1 FOREIGN KEY (FKID) REFERENCES T1 (ID); --succeeds 
ALTER TABLE T2 CHECK CONSTRAINT FK_T2_T1; --succeeds since the CONSTRAINT is attributed as NOCHECK 

--Attempt to enable CONSTRAINT fails due to orphans 
ALTER TABLE T2 WITH CHECK CHECK CONSTRAINT FK_T2_T1; --fails 

--Remove orphans 
DELETE FROM T2 WHERE FKID NOT IN (SELECT ID FROM T1); 

--Enabling the CONSTRAINT succeeds 
ALTER TABLE T2 WITH CHECK CHECK CONSTRAINT FK_T2_T1; --succeeds; orphans removed 

--Clean up 
DROP TABLE T2; 
DROP TABLE T1; 

Answer 6

tiếp tục cho ý kiến ​​tuyệt vời ở trên về những hạn chế đáng tin cậy:

select * from sys.foreign_keys where is_not_trusted = 1 ; 
select * from sys.check_constraints where is_not_trusted = 1 ; 

Một hạn chế không tin cậy , giống như tên gọi của nó, không thể tin cậy để thể hiện chính xác trạng thái của dữ liệu trong bảng ngay bây giờ. Nó có thể, tuy nhiên, nhưng có thể được tin cậy để kiểm tra dữ liệu được thêm vào và sửa đổi trong tương lai.

Ngoài ra, các ràng buộc không tin cậy được bỏ qua bởi trình tối ưu hóa truy vấn.

Mã để bật ràng buộc kiểm tra và ràng buộc khóa ngoài là khá xấu, với ba nghĩa của từ "kiểm tra".

ALTER TABLE [Production].[ProductCostHistory] 
WITH CHECK -- This means "Check the existing data in the table". 
CHECK CONSTRAINT -- This means "enable the check or foreign key constraint". 
[FK_ProductCostHistory_Product_ProductID] -- The name of the check or foreign key constraint, or "ALL". 

Answer 7

Dưới đây là một số mã tôi đã viết để giúp chúng tôi xác định và sửa chữa CONSTRAINT không đáng tin cậy trong DATABASE. Nó tạo mã để khắc phục từng vấn đề.

;WITH Untrusted (ConstraintType, ConstraintName, ConstraintTable, ParentTable, IsDisabled, IsNotForReplication, IsNotTrusted, RowIndex) AS 
(
    SELECT 
     'Untrusted FOREIGN KEY' AS FKType 
     , fk.name AS FKName 
     , OBJECT_NAME(fk.parent_object_id) AS FKTableName 
     , OBJECT_NAME(fk.referenced_object_id) AS PKTableName 
     , fk.is_disabled 
     , fk.is_not_for_replication 
     , fk.is_not_trusted 
     , ROW_NUMBER() OVER (ORDER BY OBJECT_NAME(fk.parent_object_id), OBJECT_NAME(fk.referenced_object_id), fk.name) AS RowIndex 
    FROM 
     sys.foreign_keys fk 
    WHERE 
     is_ms_shipped = 0 
     AND fk.is_not_trusted = 1  

    UNION ALL 

    SELECT 
     'Untrusted CHECK' AS KType 
     , cc.name AS CKName 
     , OBJECT_NAME(cc.parent_object_id) AS CKTableName 
     , NULL AS ParentTable 
     , cc.is_disabled 
     , cc.is_not_for_replication 
     , cc.is_not_trusted 
     , ROW_NUMBER() OVER (ORDER BY OBJECT_NAME(cc.parent_object_id), cc.name) AS RowIndex 
    FROM 
     sys.check_constraints cc 
    WHERE 
     cc.is_ms_shipped = 0 
     AND cc.is_not_trusted = 1 

) 
SELECT 
    u.ConstraintType 
    , u.ConstraintName 
    , u.ConstraintTable 
    , u.ParentTable 
    , u.IsDisabled 
    , u.IsNotForReplication 
    , u.IsNotTrusted 
    , u.RowIndex 
    , 'RAISERROR(''Now CHECKing {%i of %i)--> %s ON TABLE %s'', 0, 1' 
     + ', ' + CAST(u.RowIndex AS VARCHAR(64)) 
     + ', ' + CAST(x.CommandCount AS VARCHAR(64)) 
     + ', ' + '''' + QUOTENAME(u.ConstraintName) + '''' 
     + ', ' + '''' + QUOTENAME(u.ConstraintTable) + '''' 
     + ') WITH NOWAIT;' 
    + 'ALTER TABLE ' + QUOTENAME(u.ConstraintTable) + ' WITH CHECK CHECK CONSTRAINT ' + QUOTENAME(u.ConstraintName) + ';' AS FIX_SQL 
FROM Untrusted u 
CROSS APPLY (SELECT COUNT(*) AS CommandCount FROM Untrusted WHERE ConstraintType = u.ConstraintType) x 
ORDER BY ConstraintType, ConstraintTable, ParentTable;