Sql Server 2008 확인 제한

Question

동일한 기본 키 (FKTestID)가있는 Table1과 Table2의 두 테이블이 있습니다.
Table1에서 하나의 행을 삭제하고 동일한 FKTestID가 Table2에있는 경우 작동하지 않습니다. Table1.FKTestID가 Table2의 FKTestID와 같지 않으면 Table1에서 행만 삭제할 수 있습니다.

이 제약 사항을 도와주십시오.

Answer 1

삭제시 계단식으로 제약 조건을 설정해야합니다.

제약 조건을 수정하여 SQL 관리 스튜디오를 통해이 작업을 수행 할 수 있습니다.

아니면 말

당신은 ALTER TABLE command 함께 할도 수에 ON DELETE CASCADE을 포함하여 제약 조건을 만들 때 당신은 SQL을 통해이 작업을 수행 할 수 있습니다.

Answer 2

다음은 Simon이 위에 제안한 것을 구현하는 코드 샘플입니다.

CREATE TABLE dbo.Table1 (
    FKTestID int NOT NULL PRIMARY KEY 
) 
GO 

CREATE TABLE dbo.Table2 (
    FKTestID int NOT NULL PRIMARY KEY 
) 
GO 

ALTER TABLE dbo.Table2 
ADD CONSTRAINT FK_Table2_FKTestID 
FOREIGN KEY (FKTestID) 
REFERENCES dbo.Table1 (FKTestID) 
ON DELETE CASCADE 
GO 

INSERT INTO dbo.Table1 VALUES (1) 
INSERT INTO dbo.Table2 VALUES (1) 
INSERT INTO dbo.Table1 VALUES (2) 
INSERT INTO dbo.Table2 VALUES (2) 

DELETE FROM dbo.Table1 WHERE FKTestID = 1 

SELECT 'Table1' AS [Table], * FROM dbo.Table1 
SELECT 'Table2' AS [Table], * FROM dbo.Table2 

============================================= 

Table  FKTestID 
------ ----------- 
Table1   2 

Table  FKTestID 
------ ----------- 
Table2   2 

나는 CASCADE DELETE가 위험하다는 Mitch Wheat의 의견에 동의합니다. 이 기능은 흥미 롭습니다. 그러나 프로덕션 시스템에서이 기능을 사용 해보지 않았습니다.

Answer 3

제약 조건을 없애 버릴 수있는 방법을 묻는다면 삭제하지 말라. 제약 조건은 이유가 있습니다. 이유를 모르는 경우 삭제하지 마십시오.

다른 사람들은 계단식 삭제를 제안했습니다. 데이터베이스 성능 문제가 발생할 수 있으므로 이것이 바람직하지 않은 아이디어라고 제안합니다. 올바른 순서로 레코드를 삭제하는 스크립트를 작성하는 것이 좋습니다. 이 경우 먼저 테이블 2에서 일치하는 레코드를 삭제 한 다음 테이블 1에서 삭제를 실행해야합니다.

또한 스크립트 또는 캐스케이드 delte로 테이블 2에서 데이터를 삭제하기 전에 table2의 데이터를 평가해야합니다. table2에서 레코드를 삭제하면 안되면 제약 조건을 제거하여 table1의 레코드를 삭제하면 안됩니다. 그러면 테이블 2 레코드가 분리되어 고아가됩니다. 그러면 데이터의 무결성이 손실됩니다. 모든 데이터베이스 작업 (보안 및 성능이 매우 근접한 두 번째 및 세 번째)에서 가장 먼저 고려해야 할 사항입니다.

표 2의 데이터가 레코드를 삭제하지 말아야한다는 것을 나타내는 시나리오를 알려 드리겠습니다. 고객 테이블 및 주문 테이블이 있다고 가정합니다. 고객 A를 삭제하려고하지만 그는 과거에 주문을했습니다. 두 레코드를 모두 삭제하면 주문에 대한 모든 회계 정보가 엉망이됩니다. 고객을 삭제하고 주문을 삭제하는 경우 (제약 조건을 제거함) 주문이 발송자에게 더 이상 전달되지 않을 수 있습니다. 이와 같은 경우에 올바른 작업은 고객 테이블에 ISactive 파일을 작성하여 비활성 고객으로 표시하는 것입니다. 물론 고객 정보를 검색하는 코드를 재 설계하여 적극적인 고객만을 선택하는 플래그를 포함시켜야합니다. 이러한 이유 때문에 나중에 개발을 시작할 때이 종류의 것을 고려해야합니다 (왜 그런지 이유 중 하나입니다. 시간이 지남에 따라 설계 프로세스의 일부로 데이터를 유지 관리하는 것을 고려하지 않는 많은 응용 프로그램 개발자가 있으므로 설계 단계에서 데이터베이스 전문가를 고용 할 가치가 있습니다.