계층 구조가있는 테이블 : 외래 키를 통한 순환을 방지하기위한 제약 조건 만들기

다음과 같이 외래 키 제약 조건이있는 테이블이 있다고 가정합니다.

CREATE TABLE Foo 
    (FooId BIGINT PRIMARY KEY,
     ParentFooId BIGINT,
     FOREIGN KEY([ParentFooId]) REFERENCES Foo ([FooId]) )

INSERT INTO Foo (FooId, ParentFooId) 
VALUES (1, NULL), (2, 1), (3, 2)

UPDATE Foo SET ParentFooId = 3 WHERE FooId = 1

이 테이블에는 다음과 같은 레코드가 있습니다.

FooId  ParentFooId
-----  -----------
1      3
2      1
3      2

이런 종류의 디자인이 이해 될 수있는 경우가 있습니다 (예 : 전형적인 "직원과 보스-직원"관계).

이런 종류의 디자인은 불행히도 위의 예와 같이 데이터 레코드의 순환 성을 허용합니다.

내 질문은 다음과 같습니다

1. 이것을 확인하는 제약 조건을 작성할 수 있습니까? 과
2. 이것을 확인하는 제약 조건을 작성하는 것이 가능 합니까? (특정 깊이에만 필요한 경우)

이 질문의 (2) 부분에 대해서는 일반적으로 약 5-10 레벨보다 깊게 중첩되지 않은 테이블에 수백 개 또는 경우에 따라 수천 개의 레코드 만 기대한다는 언급과 관련이있을 수 있습니다.

추신. MS SQL Server 2008

2012 년 3 월 14 일 업데이트
몇 가지 좋은 답변이있었습니다. 나는 이제 언급 된 가능성 / 타당성을 이해 하는 데 도움이되는 것을 받아 들였습니다 . 그래도 구현 제안이있는 몇 가지 다른 훌륭한 답변이 있으므로 동일한 질문으로 여기에 도착하면 모든 답변을 살펴보십시오.)

이러한 구속 조건을 적용하기 어려운 인접 목록 모델을 사용하고 있습니다.

실제 계층 만 나타낼 수있는 중첩 집합 모델을 검사 할 수 있습니다 (원형 경로 없음). 그러나 느린 삽입 / 업데이트와 같은 다른 단점이 있습니다.

나는 이것을 시행하는 두 가지 주요 방법을 보았다.

1, 오래된 방법 :

CREATE TABLE Foo 
    (FooId BIGINT PRIMARY KEY,
     ParentFooId BIGINT,
     FooHierarchy VARCHAR(256),
     FOREIGN KEY([ParentFooId]) REFERENCES Foo ([FooId]) )

FooHierarchy 열에는 다음과 같은 값이 포함됩니다.

"|1|27|425"

숫자가 FooId 열에 매핑되는 위치 그런 다음 계층 열이 "| id"로 끝나고 나머지 문자열이 PARENT의 FooHieratchy와 일치하도록 강제합니다.

2, 새로운 방법 :

SQL Server 2008에는 HierarchyID 라는 새로운 데이터 유형 이 있습니다.

OLD 방식과 동일한 보안 주체에서 작동하지만 SQL Server에서 효율적으로 처리하며 "ParentID"열의 REPLACEMENT로 사용하기에 적합합니다.

CREATE TABLE Foo 
    (FooId BIGINT PRIMARY KEY,
     FooHierarchy HIERARCHYID )

CHECK 제약 조건에서 스칼라 UDF를 호출 할 수 있으며 모든 길이의주기를 감지 할 수 있습니다. 불행히도이 접근 방식은 매우 느리고 신뢰할 수 없습니다. 오 탐지 및 오 탐지를 가질 수 있습니다.

대신 구체화 된 경로를 사용합니다.

사이클을 피하는 또 다른 방법은 CHECK (ID> ParentID)를 사용하는 것인데, 이는 아마도 그다지 실현되지 않을 것입니다.

순환을 피하는 또 다른 방법은 LevelInHierarchy 및 ParentLevelInHierarchy라는 두 개의 열을 추가하고 (ParentID, ParentLevelInHierarchy)가 (ID, LevelInHierarchy)를 참조하고 CHECK (LevelInHierarchy> ParentLevelInHierarchy)를 갖는 것입니다.

나는 그것이 가능하다고 믿는다.

create function test_foo (@id bigint) returns bit
as
begin
declare @retval bit;

with t1 as (select @id as FooId, 0 as lvl  
union all 
 select f.FooId , t1.lvl+1 from t1 
 inner join Foo f ON (f.ParentFooId = t1.FooId)
 where lvl<11) -- you said that max nested level 10, so if there is any circular   
-- dependency, we don't need to go deeper than 11 levels to detect it

 select @retval =
 CASE(COUNT(*)) 
 WHEN 0 THEN 0 -- for records that don't have children
 WHEN 1 THEN 0 -- if a record has children
  ELSE 1 -- recursion detected
 END
 from t1
 where t1.FooId = @id ;

return @retval; 
end;
GO
alter table Foo add constraint CHK_REC1 CHECK (dbo.test_foo(ParentFooId) = 0)

나는 뭔가를 놓쳤을 수도 있지만 (죄송합니다. 완전히 테스트 할 수는 없습니다), 작동하는 것 같습니다.

다른 옵션은 다음과 같습니다. 여러 행 업데이트를 허용하고주기를 적용하지 않는 트리거입니다. 루트 요소 (부모 NULL 포함)를 찾을 때까지 조상 체인을 통과하여 작동하므로 사이클이 없음을 증명합니다. 물론 사이클은 끝이 없기 때문에 10 세대로 제한됩니다.

현재 수정 된 행 세트에서만 작동하므로 업데이트가 테이블의 매우 많은 수의 매우 깊은 항목에 닿지 않는 한 성능이 나쁘지 않아야합니다. 각 요소의 체인까지 올라 가야하므로 성능에 약간의 영향을 미칩니다.

진정으로 "지능적인"트리거는 항목이 자체에 도달했는지 확인한 다음 bailing하여 직접 사이클을 찾습니다. 그러나 이것은 각 루프 중에 이전에 찾은 모든 노드의 상태를 확인해야하므로 WHILE 루프와 현재 원하는 것보다 많은 코딩이 필요합니다. 정상적인 작업에는 사이클이 없기 때문에 더 비싸지 않아야 하며이 경우 각 루프 동안 모든 이전 노드가 아닌 이전 세대로만 작업하는 것이 더 빠릅니다.

@AlexKuznetsov 또는 다른 사람이 스냅 샷 격리에서 어떻게 작용하는지에 대한 의견을 듣고 싶습니다. 나는 그것이 잘되지 않을 것이라고 생각하지만 더 잘 이해하고 싶습니다.

CREATE TRIGGER TR_Foo_PreventCycles_IU ON Foo FOR INSERT, UPDATE
AS
SET NOCOUNT ON;
SET XACT_ABORT ON;

IF EXISTS (
   SELECT *
   FROM sys.dm_exec_session
   WHERE session_id = @@SPID
   AND transaction_isolation_level = 5
)
BEGIN;
  SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
END;
DECLARE
   @CycledFooId bigint,
   @Message varchar(8000);

WITH Cycles AS (
   SELECT
      FooId SourceFooId,
      ParentFooId AncestorFooId,
      1 Generation
   FROM Inserted
   UNION ALL
   SELECT
      C.SourceFooId,
      F.ParentFooId,
      C.Generation + 1
   FROM
      Cycles C
      INNER JOIN dbo.Foo F
         ON C.AncestorFooId = F.FooId
   WHERE
      C.Generation <= 10
)
SELECT TOP 1 @CycledFooId = SourceFooId
FROM Cycles C
GROUP BY SourceFooId
HAVING Count(*) = Count(AncestorFooId); -- Doesn't have a NULL AncestorFooId in any row

IF @@RowCount > 0 BEGIN
   SET @Message = CASE WHEN EXISTS (SELECT * FROM Deleted) THEN 'UPDATE' ELSE 'INSERT' END + ' statement violated TRIGGER ''TR_Foo_PreventCycles_IU'' on table "dbo.Foo". A Foo cannot be its own ancestor. Example value is FooId ' + QuoteName(@CycledFooId, '"') + ' with ParentFooId ' + Quotename((SELECT ParentFooId FROM Inserted WHERE FooID = @CycledFooId), '"');
   RAISERROR(@Message, 16, 1);
   ROLLBACK TRAN;   
END;

최신 정보

Inserted 테이블에 추가 조인을 피하는 방법을 알아 냈습니다. 누구든지 NULL을 포함하지 않는 것을 감지하기 위해 GROUP BY를 수행하는 더 좋은 방법을 알고 있다면 알려주십시오.

또한 현재 세션이 SNAPSHOT ISOLATION 레벨 인 경우 READ COMMITTED에 스위치를 추가했습니다. 불행하게도 차단이 증가하지만 불일치를 방지합니다. 그것은 당면한 일에 피할 수없는 일입니다.

레코드가 1 레벨 이상 중첩되면 제약 조건이 작동하지 않습니다 (예를 들어 레코드 1이 레코드 2의 부모이고 레코드 3이 레코드 1의 부모라는 것을 의미한다고 가정합니다). 이 작업을 수행하는 유일한 방법은 부모 코드 또는 트리거를 사용하는 것이지만 큰 테이블과 여러 수준을 보는 경우 상당히 집중적입니다.