복합 외래 키에 별도의 고유 제약 조건이 필요한 이유는 무엇입니까?

다음은 레코드가 동일한 테이블에서 상위 레코드를 참조 할 수있는 간단한 테이블입니다.

CREATE TABLE foo (
    id         SERIAL  PRIMARY KEY,
    parent_id  INT     NULL,
    num        INT     NOT NULL,
    txt        TEXT    NULL,
    FOREIGN KEY (parent_id) REFERENCES foo(id)
);

다른 필드 값 중 하나 ( num)가 부모 레코드와 자식 레코드 사이에 동일해야 한다는 추가 요구 사항으로 인해 복합 외래 키가 트릭을 수행해야한다고 생각했습니다. 마지막 줄을

    FOREIGN KEY (parent_id, num) REFERENCES foo(id, num)

그리고 오류가 발생했습니다 : 참조 테이블 "foo"에 대해 주어진 키와 일치하는 고유 제약 조건이 없습니다 .

이 제약 조건을 쉽게 추가 할 수 있지만 참조 된 열 ( id) 중 하나 가 이미 고유 한 것으로 보장 될 때 왜 필요한지 이해하지 못 합니까? 내가 보는 방식으로 새로운 제약 조건은 중복됩니다.

내가 아는 한 DBMS의 한계입니다. 열을 추가 할 때뿐만 아니라 열을 다시 정렬 할 때도 마찬가지입니다. 우리가있는 경우 UNIQUE제약에 (a1, a2), 우리는 추가 할 수 없습니다 FOREIGN KEY것을 REFERENCES (a2, a1)그에 고유 제한 조건이없는 한 (a2, a1)기본적으로 중복됩니다.

이것을 기능으로 추가하는 것은 끔찍한 일이 아닙니다.

거기 경우 UNIQUE에 제약 (a)어떤 다음, (a, b, c, ..., z)또는 (b,c, ...a, ...z)조합도 보장됩니다 UNIQUE.

또는 일반화 :

UNIQUE제한 이있는 (a1, a2, ..., aN)경우 모든 (a1, a2, ..., aN, b1, b2, ..., bM)조합 또는 재배치도 보장 UNIQUE됩니다.

요청되지 않았거나 구현하기에 충분한 우선 순위로 간주되지 않은 것 같습니다.

언제든지 해당 채널에서 기능을 구현하도록 요청할 수 있습니다. 또는 DBMS가 Postgres와 같은 오픈 소스 인 경우 직접 구현하십시오.

일반적으로 외래 키 (복합이 아닌)는 다른 테이블에서 일종의 고유 키를 가리켜 야합니다. 그렇지 않은 경우 관계형 데이터 무결성이 없습니다.

(id)에 고유 키가있는 동안 .. (id, num)에 고유 키가 없습니다. 따라서 DB에 관한 한 쌍 (id, num)은 다음과 같습니다. 독창적이라고 보장되지 않습니다. 우리는 인간으로서 독특하다는 것을 알 수 있지만 Postgres를 똑똑하게 만들기 위해 추가해야 할 많은 추가 코드가있을 것이라고 확신합니다. "oh hey .. id는 고유해야합니다. 따라서 id, num도 고유해야합니다. "

문제를 해결하기 위해 두 열에 다른 고유 인덱스를 만드는 것만으로도 해당 코드를 추가하면 매우 놀랄 것입니다.

분명히 말하면, 그들이 추가해야 할 코드는이 단순한 경우가 아니라 외래 키가 4+ 열에있는 경우 등 모든 경우를 처리해야 할 것입니다. 논리는 상당히 복잡합니다.