기본 키 / 외래 키 명명 규칙 [닫힘]

개발 그룹에서는 기본 및 외래 키의 명명 규칙에 대해 격렬한 논쟁이 있습니다. 우리 그룹에는 기본적으로 두 가지 학파가 있습니다.

1:

Primary Table (Employee)   
Primary Key is called ID

Foreign table (Event)  
Foreign key is called EmployeeID

또는

2 :

Primary Table (Employee)  
Primary Key is called EmployeeID

Foreign table (Event)  
Foreign key is called EmployeeID

어떤 열에도 테이블 이름을 복제하지 않는 것을 선호합니다 (따라서 위의 옵션 1을 선호합니다). 개념적으로는 속성 이름에 개체 이름을 사용하지 않는 다른 언어의 많은 권장 사례와 일치합니다. 외래 키 EmployeeID(또는 Employee_ID더 좋을 수도 있음)의 이름을 지정 하면 독자에게 그것이IDEmployee 테이블 열 .

다른 일부는 열 이름이 데이터베이스 전체에서 동일하도록 테이블 이름이 접두어로 붙은 기본 키의 이름을 지정하는 옵션 2를 선호합니다. 그 점을 알지만 이제는 기본 키와 외래 키를 시각적으로 구분할 수 없습니다.

또한, 나는 당신이 개체와 그 개체의 속성이나 속성으로 컬럼과 테이블을 생각하면, 당신은의 ID 속성으로 생각하기 때문에, 열 이름에 테이블 이름을 가지고 중복 생각 Employee하지 EmployeeID직원 의 속성. 나는 그의 것을 내 동료에게 가지 않는다 PersonAge또는 PersonGender이다. 나는 그에게 그의 나이가 무엇인지 묻습니다.

그래서 제가 말했듯이, 그것은 격렬한 논쟁이며 우리는 그것에 대해 계속해서 계속합니다. 새로운 관점을 얻고 싶습니다.

별로 중요하지 않습니다. 나는 선택 1과 선택 2 사이에 실질적인 차이가있는 시스템을 본 적이 없습니다.

Jeff Atwood는이 주제에 대한 훌륭한 기사를 가지고있었습니다. 기본적으로 사람들은 자신이 잘못 증명할 수없는 주제에 대해 가장 격렬하게 토론하고 논쟁합니다. 또는 다른 각도에서, 필리 버스터 스타일의 지구력 기반 최후의 주장을 통해서만 이길 수있는 주제.

하나를 선택하고 실제로 코드에 영향을 미치는 문제에 집중하도록 지시하십시오.

편집 : 재미를 원한다면 재귀 테이블 참조에 대해 방법이 우수한 이유를 길게 지정하십시오.

두 열의 이름이 두 테이블 모두에서 동일한 경우 (컨벤션 # 2) SQL에서 USING 구문을 사용하여 입력 및 상용구 노이즈를 줄일 수 있습니다.

SELECT name, address, amount
  FROM employees JOIN payroll USING (employee_id)

관례 # 2를 찬성하는 또 다른 주장은 이것이 관계형 모델 이 설계된 방식이라는 것 입니다.

각 열의 중요성은 해당 도메인의 이름으로 레이블을 지정하여 부분적으로 전달됩니다.

신청 방법에 따라 다릅니다. ORM을 사용하거나 테이블을 디자인하여 개체를 나타내는 경우 옵션 1이 적합 할 수 있습니다.

데이터베이스를 자체 레이어로 코딩하고 싶습니다. 나는 모든 것을 제어하고 앱은 저장 프로 시저 만 호출합니다. 특히 조인 된 테이블이 많고 많은 열이 반환되는 경우 완전한 열 이름을 가진 결과 집합을 갖는 것이 좋습니다. 이 유형의 응용 프로그램에서는 옵션 2를 좋아합니다. 조인에서 열 이름이 일치하는 것을보고 싶습니다. 나는 그들이 일치하지 않는 오래된 시스템에서 일했고 그것은 악몽이었습니다.

두 규칙 모두 모든 경우에 작동하지 않는데, 왜 하나를 가지고 있습니까? 상식 사용 ...

예를 들어 자체 참조 테이블의 경우 동일한 테이블의 PK를 자체 참조하는 FK 열이 두 개 이상있는 경우 두 FK 열의 이름을 동일하게 지정할 수 없으므로 두 "표준"을 모두 위반해야합니다. , EmployeeId PK, SupervisorId FK, MentorId Fk, PartnerId FK, ...

나는 그들 중 선택할 것이 거의 없다는 데 동의합니다. 나에게 어느 표준에 대해 훨씬 더 중요한 것은 "표준"부분입니다.

사람들이 '자신의 일을하기'시작한다면 그들은 네더에 의해 묶여 져야합니다. IMHO :)

다음을 고려해 보셨습니까?

Primary Table (Employee)   
Primary Key is PK_Employee

Foreign table (Event)  
Foreign key is called FK_Employee

내가 일하는 곳에서 사용하는 규칙은 A와 매우 비슷하지만, 복수형 (즉, "employees")으로 테이블 이름을 지정하고 테이블과 열 이름 사이에 밑줄을 사용한다는 점만 제외하면됩니다. 이것의 장점은 열을 참조 할 때 액세스하려는 방법에 따라 "employees _ id"또는 "employees.id"라는 것입니다. 열이 나오는 테이블을 지정해야하는 경우 "employees.employees _ id"는 확실히 중복됩니다.

데이터베이스 쿼리뿐만 아니라 응용 프로그램 코드를보고 있다면 다음과 같은 사항이 분명해 보입니다.

1. 테이블 정의는 일반적으로 하나의 객체를 설명하는 클래스에 직접 매핑되므로 단수 여야합니다. 객체의 컬렉션을 설명하기 위해 저는 일반적으로 단수 이름에 "Array", "List"또는 "Collection"을 추가합니다. 이는 복수형을 사용하는 것보다 더 명확하게 그것이 컬렉션이라는 것을 의미 할뿐만 아니라 어떤 종류의 컬렉션인지를 나타냅니다. 그것은. 이보기에서 테이블 이름은 컬렉션의 이름이 아니라 컬렉션이 속한 개체 유형의 이름으로 표시됩니다. 애플리케이션 코드를 작성하지 않는 DBA는이 점을 놓칠 수 있습니다.

2. 내가 다루는 데이터는 종종 키가 아닌 식별 목적으로 "ID"를 사용합니다. 키 "ID"와 키가 아닌 "ID"간의 혼동을 없애기 위해 기본 키 이름에 대해 테이블 ​​이름이나 약어가 접두사로 붙은 "키"(그렇지 않습니까?)를 사용합니다. 테이블 이름. 이 접두사 (그리고 저는 이것을 기본 키에 대해서만 예약합니다)는 키 이름을 고유하게 만듭니다. 이는 데이터베이스 열 이름과 동일한 변수 이름을 사용하고 대부분의 클래스에는 다음 이름으로 식별되는 부모가 있기 때문에 특히 중요합니다. 부모 키. 이것은 또한 "Key"만있는 예약 된 키워드가 아닌지 확인하는 데 필요합니다. 키 변수 이름의 일관성을 유지하고 자연스러운 조인을 수행하는 프로그램을 제공하기 위해 외래 키는 기본 키인 테이블에 사용 된 것과 동일한 이름을 갖습니다. 자연 조인을 사용하여 이런 방식으로 훨씬 잘 작동하는 프로그램을 한 번 이상 접했습니다. 이 마지막 지점에서 내가 사용한 자체 참조 테이블에 문제가 있음을 인정합니다. 이 경우 외래 키 명명 규칙에 예외를 적용합니다. 예를 들어, Employee 테이블에서 ManagerKey를 외래 키로 사용하여 해당 테이블의 다른 레코드를 가리 킵니다.

나는 컨벤션 # 2를 좋아합니다.이 주제를 조사하고 내 질문을 게시하기 전에이 질문을 찾는 과정에서 다음과 같은 문제가 발생했습니다.

많은 수의 열이있는 테이블에서 *를 선택하고 비슷하게 많은 수의 열이있는 두 번째 테이블에 결합합니다. 두 테이블 모두 기본 키로 "id"열이 있으며 이는 결과에서이 두 값을 고유하게 만들기 위해 모든 열 (내가 아는 한)을 구체적으로 선택해야 함을 의미합니다.

SELECT table1.id AS parent_id, table2.id AS child_id

난 여전히 같은 이름을 가진 결과의 일부 열이있을 것이다 컨벤션 # 2 수단을 사용하지만, 지금은 지정할 수 있는 스티븐 Huwig는 제안으로, 아이디 I 필요 (부모 또는 자녀)과 USING더 문 단순화 것을.

난 항상 사용했던 사용자 ID 하나의 테이블에 PK로 userId를 FK 같은 다른 테이블에. userIdPK 와 userIdFK 를 이름으로 사용하여 서로 를 식별 하는 것에 대해 진지하게 생각하고 있습니다. 테이블을 볼 때 PK와 FK를 빠르게 식별하는 데 도움이 될 것이며 PHP / SQL을 사용하여 데이터에 액세스 할 때 코드를 정리하여 이해하기 쉽게하는 것 같습니다. 특히 다른 사람이 내 코드를 볼 때.

나는 규칙 # 2를 사용합니다. 주어진 테이블에서 의미하는 바를 모르는 레거시 데이터 모델로 작업하고 있습니다. 장황함에 대한 해악은 어디에 있습니까?

외래 키 이름을 지정하는 방법

role_id

여기서 role은 참조 된 엔티티가 현재 테이블에 상대적인 역할입니다. 이것은 동일한 테이블에 대한 재귀 참조 및 다중 fks 문제를 해결합니다.

대부분의 경우 참조 된 테이블 이름과 동일합니다. 이 경우 제안 중 하나와 동일하게됩니다.

어쨌든 긴 논쟁을하는 것은 나쁜 생각이다

""employee INNER JOIN order ON order.employee_id = employee.id "어디에 추가 자격이 필요합니까?"

내가 말한 자격이 이미 있기 때문에 추가 자격이 필요하지 않습니다.

"비즈니스 사용자가 주문 ID 또는 직원 ID를 참조하는 이유는 컨텍스트를 제공하기위한 것이지만 데이터베이스 수준에서는 테이블을 참조하기 때문에 이미 컨텍스트가 있습니다."

열이 'ID'로 명명 된 경우 내가 말한 방식대로 ID 열에 대한이 참조를 정확하게 규정하지 않는 한 "표에 대한 [원문] 참조"가 정확히 어떻게 수행됩니까?