외래 키 명명 체계

처음으로 외래 키 작업을 시작했으며 표준 명명 체계가 있는지 궁금합니다.

이러한 테이블이 주어지면 :

task (id, userid, title)
note (id, taskid, userid, note);
user (id, name)

작업에 메모가있는 경우 사용자는 작업을 소유하며 사용자는 메모를 작성합니다.

이 상황에서 세 개의 외래 키는 어떻게 명명됩니까? 아니면 전혀 문제가되지 않습니까?

업데이트 :이 질문은 필드 이름이 아닌 외래 키 이름에 관한 것입니다!

SQL Server의 표준 규칙은 다음과 같습니다.

FK_ForeignKeyTable_PrimaryKeyTable

예를 들어 메모와 작업의 핵심은 다음과 같습니다.

FK_note_task

작업과 사용자 사이의 핵심은 다음과 같습니다.

FK_task_user

이를 통해 어떤 테이블이 키와 관련되어 있는지 한 눈에 볼 수 있으므로 특정 테이블 (첫 번째 테이블)이 어떤 테이블 (두 번째 테이블)에 의존하는지 쉽게 볼 수 있습니다. 이 시나리오에서 전체 키 세트는 다음과 같습니다.

FK_task_user
FK_note_task
FK_note_user

따라서 작업이 사용자에 의존하고 메모가 작업과 사용자에 의존한다는 것을 알 수 있습니다.

구분 기호로 두 개의 밑줄 문자를 사용합니다.

fk__ForeignKeyTable__PrimaryKeyTable 

테이블 이름에 때때로 밑줄 문자가 포함되기 때문입니다. 데이터 요소의 이름은 종종 밑줄 문자를 포함하기 때문에 제약 조건의 명명 규칙을 따릅니다.

CREATE TABLE NaturalPersons (
   ...
   person_death_date DATETIME, 
   person_death_reason VARCHAR(30) 
      CONSTRAINT person_death_reason__not_zero_length
         CHECK (DATALENGTH(person_death_reason) > 0), 
   CONSTRAINT person_death_date__person_death_reason__interaction
      CHECK ((person_death_date IS NULL AND person_death_reason IS NULL)
              OR (person_death_date IS NOT NULL AND person_death_reason IS NOT NULL))
        ...

어때요 FK_TABLENAME_COLUMNNAME?

K EEP I t S imple S tupid 보입니다.

SQL Server에 관한 Microsoft의 참고 사항 :

FOREIGN KEY 제약 조건은 다른 테이블의 PRIMARY KEY 제약 조건에만 연결될 필요는 없습니다. 다른 테이블에서 UNIQUE 제약 조건의 열을 참조하도록 정의 할 수도 있습니다.

따라서 기존의 기본 / 외국 관계 용어 대신 종속성을 설명하는 용어를 사용합니다.

종속 (자식) 테이블 에서 비슷한 이름의 열 (들)에 의해 독립 (부모) 테이블 의 PRIMARY KEY를 참조 할 때 열 이름을 생략합니다.

FK_ChildTable_ParentTable

다른 열을 참조하거나 열 이름이 두 테이블간에 다르거 나 명시 적으로 나타납니다.

FK_ChildTable_childColumn_ParentTable_parentColumn

나는 보통 PK라는 id를 남겨두고 다른 테이블에서 FK를 명명 할 때 테이블 이름과 키 열 이름을 연결합니다. 일부 데이터베이스는 대소 문자를 구분하지 않고 어쨌든 모든 대문자 또는 소문자 이름을 반환하기 때문에 낙타 케이싱을 사용하지 않습니다. 어쨌든, 내 테이블 버전은 다음과 같습니다.

task (id, userid, title);
note (id, taskid, userid, note);
user (id, name);

행은 내가 유지하는 객체 중 하나를 나타 내기 때문에 표 이름을 단수로 지정합니다. 이러한 규칙 중 많은 부분이 개인 취향입니다. 다른 사람의 컨벤션을 채택하는 것보다 컨벤션을 선택하고 항상 사용하는 것이 더 중요하다고 제안합니다.

이것은 아마도 과잉 살상이지만 나를 위해 일합니다. VLDB를 다룰 때 특히 도움이됩니다. 나는 다음을 사용한다 :

CONSTRAINT [FK_ChildTableName_ChildColName_ParentTableName_PrimaryKeyColName]

물론 어떤 이유로 든 기본 키를 참조하지 않는 경우 고유 제한 조건에 포함 된 열을 참조해야합니다 (이 경우).

CONSTRAINT [FK_ChildTableName_ChildColumnName_ParentTableName_ColumnInUniqueConstaintName]

오래 걸리 겠어요 보고서에 대한 정보를 명확하게 유지하는 데 도움이 되었습니까, 아니면 잠재적 문제가 자극 경고 중이라는 사실에 대해 빠르게 도약 했습니까? 100 %는이 명명 규칙에 대한 사람들의 생각을 알고 싶어합니다.

내 평소 접근 방식은

FK_ColumnNameOfForeignKey_TableNameOfReference_ColumnNameOfReference

또는 다른 말로하면

FK_ChildColumnName_ParentTableName_ParentColumnName

이 방법 history_info table으로 column actionBy and actionTofrom users_info테이블 과 같은 테이블을 참조하는 두 개의 외래 키 이름을 지정할 수 있습니다.

그것은 같을 것이다

FK_actionBy_usersInfo_name - For actionBy
FK_actionTo_usersInfo_name - For actionTo

참고 :

나는 아이에게 상식 인 것처럼 보이기 때문에 아이 테이블 이름을 포함시키지 않았다. 나는 아이의 테이블에 있으므로 아이의 테이블 이름을 쉽게 추측 할 수있다. 그것의 총 문자는 26이고 찰스 번즈가 언급 한 오라클의 30 자 제한에 잘 맞습니다 .

독자를위한 참고 사항 : 아래에 나열된 많은 모범 사례는 30 자 이름 제한으로 인해 Oracle에서 작동하지 않습니다. 테이블 이름 또는 열 이름은 이미 30 자에 가깝기 때문에 두 이름을 단일 이름으로 결합하는 규칙에는 잘림 표준 또는 기타 트릭이 필요합니다. – 찰스 번즈

여기에 대한 답변과 설명에 따라 FK 테이블, FK 필드 및 PK 테이블 (FK_FKTbl_FKCol_PKTbl)을 포함하는 명명 규칙은 FK 제약 조건 이름 충돌을 피해야합니다.

주어진 테이블에 대해 다음을 수행하십시오.

fk_task_userid_user
fk_note_userid_user

따라서 작업 또는 메모를 마지막으로 수정 한 사람을 추적하기 위해 열을 추가하면 ...

fk_task_modifiedby_user
fk_note_modifiedby_user

FK를 자주 참조하지 않고 MySQL (및 InnoDB)을 사용하는 경우 MySQL의 이름을 FK로 지정하면됩니다.

나중에 쿼리를 실행하여 필요한 FK 이름을 찾을 수 있습니다 .

대문자로 된 버전 4 UUID를 사용하여 첫 번째 옥텟을 '-'(대시) 대신 FK 및 '_'(밑줄)로 바꿉니다.

예 :

• FK_4VPO_K4S2_A6M1_RQLEYLT1VQYV
• FK_1786_45A6_A17C_F158C0FB343E
• FK_45A5_4CFA_84B0_E18906927B53

근거는 다음과 같습니다

• 엄격한 생성 알고리즘 => 균일 한 이름 ;
• 키 길이는 30 자 미만이며 Oracle의 이름 길이 제한 (12c 이전)입니다.
• 엔터티 이름이 변경되면 엔터티 이름 기반 방식과 같이 FK의 이름을 바꿀 필요가 없습니다 (DB가 테이블 이름 바꾸기 연산자를 지원하는 경우).
• 외래 키 제약 조건의 이름은 거의 사용하지 않습니다. 예를 들어 DB 도구는 일반적으로 제약 조건이 적용되는 것을 보여줍니다. "암호 해독"에 사용하지 않기 때문에 암호 모양을 두려워 할 필요가 없습니다.