외부 키가 고유하지 않은 인덱스를 참조할 수 있습니까?

외부 키가 고유하지 않은 인덱스를 참조할 수 있습니까?

외부 키는 한 행이 한 행을 참조해야 한다는 뜻인 줄 알았는데, 그렇지 않은 표를 보고 있습니다.표 1에는 표 2의 열 2에 외부 키 제약이 있는 열 1이 있지만, 표 2에는 같은 값을 가진 레코드가 많이 있습니다.2열에는 특이하지 않은 지수도 있습니다.이것은 무엇을 의미합니까?외부 키 제약 조건은 올바른 열에 올바른 값을 가진 레코드가 하나 이상 존재해야 한다는 의미입니까?그런 레코드가 꼭 하나 있어야 한다고 생각했다(그림에 NULL이 얼마나 잘 들어맞는지는 모르겠지만, 현시점에서는 별로 신경 쓰지 않는다).

업데이트: 이 동작은 제가 사용하던 MySQL에만 해당된다고 합니다만, 당초 질문에서는 언급하지 않았습니다.

MySQL 문서:

InnoDB를 사용하면 외부 키 제약이 고유하지 않은 키를 참조할 수 있습니다.이것은 표준 SQL로의 InnoDB 확장입니다.

단, 참조 테이블의 고유하지 않은 열에 외부 키를 사용하지 않도록 해야 하는 정확한 이유가 있습니다.즉, 이 경우 "ON DELETE CASCADE"의 의미는 무엇입니까?

이 문서에서는 다음 사항에 대해 자세히 설명합니다.

고유하지 않은 키 또는 NULL 값을 포함하는 키에 대한 외부 키 참조 처리가 제대로 정의되어 있지 않습니다(...). NULL 키가 아닌 UNIQURE(프라이머리 포함)만 참조하는 외부 키를 사용하는 것이 좋습니다.

분석 결과는 정확합니다.키가 고유할 필요는 없으며 일치하는 행 집합에 제약 조건이 적용됩니다.보통 유용한 행동은 아니지만 원하는 곳에 상황이 올 수 있습니다.

이 경우 보통 두 개의 외부 키가 서로 링크되어 있음을 의미합니다.대부분의 경우 기본 키로 키를 포함하는 테이블은 스키마에도 없습니다.

예:두 표, CAMLESS와 STUEND는 둘 다 ZIPCODE라는 열을 포함합니다.

저희가 잠깐 체크해 보면

SELECT * FROM COLLEGES JOIN STUDENTS ON COLLEGES.ZIPCODE = STUDENTS.ZIPCODE

우리는 그 관계가 여러 개라는 것을 알게 될지도 모른다.스키마에 ZIPCODE라고 하는 테이블과 ZIPCODE라는 프라이머리 키가 있으면 실제로 무슨 일이 일어나고 있는지 알 수 있습니다.

하지만 우리의 스키마에는 그런 표가 없습니다.그러나 스키마에 이러한 테이블이 없다고 해서 그러한 데이터가 존재하지 않는 것은 아닙니다.USPO 땅 어딘가에 그러한 테이블이 있습니다.그리고 College.Z.ZIP 코드와 학생.ZIPCODE는 우리가 인정하지 않더라도 해당 표에 대한 참조입니다.

이는 데이터베이스 구축보다 데이터 철학과 더 관련이 있지만 근본적인 것을 명확하게 보여줍니다. 데이터에는 우리가 발견한 특성이 있을 뿐 아니라 우리가 발명한 특성도 있습니다.물론, 우리가 발견한 것은 다른 누군가가 발명한 것일 수도 있습니다.ZIPCODE는 확실히 그렇습니다.

예, 기본적으로 모든 테이블의 모든 열에 대한 외부 키를 만들 수 있습니다.그러나 대부분의 경우 기본 키로 작성합니다.

기본 키를 가리키지 않는 외부 키를 사용하는 경우 성능을 위해 참조되는 열에 대해 고유하지 않은 인덱스를 작성할 수도 있습니다.

사용하고 있는 RDBMS에 따라 다릅니다.어떤 사람들은 암묵적으로 이런 짓을 하거나 다른 속임수를 쓰는 것 같아요.RTM.

또한 PostgreSQL은 이를 거부합니다(어쨌든 이것이 좋은 생각이라는 것을 의미하지는 않습니다.

essais=> CREATE TABLE Cities (name TEXT, country TEXT);
CREATE TABLE
essais=> INSERT INTO Cities VALUES ('Syracuse', 'USA');
INSERT 0 1
essais=> INSERT INTO Cities VALUES ('Syracuse', 'Greece');
INSERT 0 1
essais=> INSERT INTO Cities VALUES ('Paris', 'France');
INSERT 0 1
essais=> INSERT INTO Cities VALUES ('Aramits', 'France');
INSERT 0 1
essais=> INSERT INTO Cities VALUES ('Paris', 'USA');
INSERT 0 1

essais=> CREATE TABLE People (name TEXT, city TEXT REFERENCES Cities(name));
ERROR:  there is no unique constraint matching given keys for referenced table "cities"

네크로맨싱.
다른 사람들이 이미 말했듯이, 고유하지 않은 키를 외래 키로 참조해서는 안 됩니다.
그러나 (삭제 캐스케이드 위험 없이) 대신 할 수 있는 것은 (적어도 MS-SQL에서) 체크 제약 조건을 추가하는 것입니다.
이는 외부 키와 완전히 동일하지는 않지만, 적어도 유효하지 않은/고정된/데드 데이터의 삽입을 방지할 수 있습니다.

참조에 대해서는, 여기를 참조해 주세요(MS-SQL 코드를 MySQL 구문에 포토 할 필요가 있습니다).
to key(외부 에서 비프라이머리 키)

★★★★
다운 투표의 원인을 검색하면, Mysql CHECK 제약에 따르면 MySQL은 CHECK 제약 조건을 실제로 지원하지 않습니다.
호환성을 위해 DDL 쿼리에서 정의할 수 있지만 무시됩니다.

여기서 한 바와 같이 , 기, 기를 작성할 수 .BEFORE INSERT ★★★★★★★★★★★★★★★★★」BEFORE UPDATE트리거: 데이터 요구 사항이 충족되지 않을 때 오류가 발생합니다. 기본적으로는 더 큰 혼란이라는 점만 제외하면 이와 동일합니다.

질문에 대해서:

외부 키는 한 행이 한 행을 참조해야 한다는 뜻인 줄 알았는데, 그렇지 않은 표를 보고 있습니다.

모든 정상적인 RDBMS에서 이는 사실입니다.
MySQL에서 이것이 가능하다는 사실은 이러한 이유 중 하나일 뿐입니다.
MySQL은 사이트 내 RDBMS입니다.
빠른 속도일 수도 있지만 속도라는 제단에서 참조 무결성과 데이터 품질을 희생하는 것은 품질 규칙(Quality-rdbms)에 대한 제 생각은 아닙니다.
실제로 ACID에 준거하고 있지 않은 경우는, RDBMS가 전혀 기능하고 있지 않습니다.

어떤 데이터베이스를 말하는 거죠?SQL 2005에서는 고유한 제약조건(프라이머리 키 등)이 없는 열을 참조하는 외부 키 제약조건을 작성할 수 없습니다.

create table t1
(
  id int identity,
  fk int
);

create table t2
(
  id int identity,
);

CREATE NONCLUSTERED INDEX [IX_t2] ON [t2] 
(
    [id] ASC
);
ALTER TABLE t1 with NOCHECK
ADD CONSTRAINT FK_t2 FOREIGN KEY (fk)
    REFERENCES t2 (id) ;


Msg 1776, Level 16, State 0, Line 1
There are no primary or candidate keys in the referenced table 't2' 
that match the referencing column list in the foreign key 'FK_t2'.
Msg 1750, Level 16, State 0, Line 1
Could not create constraint. See previous errors.

실제로 이 작업을 수행할 수 있다면 다대다 관계를 효과적으로 구축할 수 있습니다. 이는 중간 표 없이는 불가능합니다.이 건에 대해 좀 더 듣고 싶습니다만…

관련 질문과 답변도 참조하십시오.

언급URL : https://stackoverflow.com/questions/588741/can-a-foreign-key-reference-a-non-unique-index