[sql] 데이터베이스 테이블의 ID 열 이름 지정

데이터베이스 테이블의 ID 열 이름 지정에 대한 사람들의 의견이 궁금합니다.

ID 열의 기본 키가있는 Invoices라는 테이블이있는 경우 다른 테이블과 충돌하지 않도록 해당 열을 InvoiceID라고 부르고 그것이 무엇인지 분명합니다.

내가 현재 일하는 곳에서는 모든 ID 열 ID를 호출했습니다.

따라서 그들은 다음을 수행합니다.

Select
    i.ID
,   il.ID
From
    Invoices i
    Left Join InvoiceLines il
        on i.ID = il.InvoiceID

이제 몇 가지 문제가 있습니다.
1. 선택 항목의 열에 별칭을 지정해야합니다
. 2. ID = InvoiceID가 내 두뇌에 맞지 않습니다.
3. 테이블에 별칭을 지정하지 않고 InvoiceID를 참조하면 어떤 테이블이 있는지 분명합니다. 켜져 있습니까?

주제에 대한 다른 사람들의 생각은 무엇입니까?



답변

ID는 SQL Antipattern입니다. 참조 http://www.amazon.com/s/ref=nb_sb_ss_i_1_5?url=search-alias%3Dstripbooks&field-keywords=sql+antipatterns&sprefix=sql+a를

ID가 ID 인 테이블이 많으면보고가 훨씬 더 어려워집니다. 의미를 모호하게하고 복잡한 쿼리를 읽기 어렵게 만들뿐만 아니라 별칭을 사용하여 보고서 자체를 구분해야합니다.

또한 누군가가 사용 가능한 데이터베이스에서 자연스러운 조인을 사용할만큼 어리석은 경우 잘못된 레코드에 조인하게됩니다.

일부 DB에서 허용하는 USING 구문을 사용하려면 ID를 사용할 수 없습니다.

ID를 사용하는 경우 조인 구문을 복사하는 경우 (아무도이 작업을 수행하지 않는다고 말하지 마십시오!) 조인 조건에서 별칭을 변경하는 것을 잊어 버리면 쉽게 잘못된 조인으로 끝날 수 있습니다.

그래서 당신은 이제

select t1.field1, t2.field2, t3.field3
from table1 t1
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t1.id = t3.table2id

당신이 의미했을 때

select t1.field1, t2.field2, t3.field3
from table1 t1
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t2.id = t3.table2id

id 필드로 tablenameID를 사용하면 이런 종류의 우발적 인 실수가 발생할 가능성이 훨씬 적고 찾기가 훨씬 쉽습니다.


답변

나는 항상 ID 열에 대해 TableName + ID를 선호하고 외래 키에 대해 TableName + ID를 선호했습니다. 이렇게하면 모든 테이블이 id 필드에 대해 동일한 이름을 가지며 중복 된 설명이 없습니다. 모든 테이블에 동일한 기본 키 필드 이름이 있기 때문에 이것은 나에게 더 간단 해 보입니다.

테이블을 조인하고 어떤 Id 필드가 어떤 테이블에 속하는지 알지 못하는 한, 제 생각에는이 상황을 처리하기 위해 쿼리를 작성해야합니다. 내가 일하는 곳에서는 항상 테이블 / 테이블 별칭이있는 명령문에서 사용하는 필드보다 우선합니다.


답변

최근에 우리 회사에서 이것에 대해 괴짜 싸움이있었습니다. LINQ의 출현은 중복 된 tablename + ID 패턴을 내 눈에 훨씬 더 어리석게 만들었습니다 . 가장 합리적인 사람들은 FK 를 구별하기 위해 테이블 ​​이름을 지정해야하는 방식으로 SQL을 작성하는 경우 입력 비용을 절약 할 수있을뿐만 아니라 SQL에 명확성을 추가하여 PKFK를 명확하게 볼 수있는 ID입니다 .

직원에서 e LEFT JOIN Customers c ON e.ID = c.EmployeeID

두 개가 연결되어있을뿐만 아니라 PK 이고 FK 임을 알려줍니다 . 구식 스타일에서는 이름이 잘 붙었 으면 좋겠다는 생각을해야만했습니다.


답변

우리는 사용 InvoiceID하지 ID. 이는 쿼리를 더 읽기 쉽게 만듭니다 ID. 특히 테이블의 별칭을 i.


답변

나는 테이블의 PK가 단순히 Id 여야하고 외래 키가 OtherTable + Id를 나열해야한다는 Keven과 다른 사람들의 의견에 동의합니다.

그러나 나는 최근에이 주장에 더 큰 비중을 둔 한 가지 이유를 추가하고 싶다.

현재 위치에서 우리는 POCO 생성을 사용하는 엔티티 프레임 워크를 사용하고 있습니다. Id의 표준 명명 규칙을 사용하면 PK는 유효성 검사를 통해 기본 poco 클래스를 상속 할 수 있으며 공통 열 이름 집합을 공유하는 테이블에 대해서도 마찬가지입니다. 이러한 각 테이블에 대해 Tablename + Id를 PK로 사용하면 이러한 테이블에 대해 기본 클래스를 사용하는 기능이 손상됩니다.

생각할 음식이 있습니다.


답변

내 선호도는 기본 키의 ID와 외래 키의 TableNameID입니다. 또한 사용자가 읽을 수있는 항목 식별자 (예 : 이름 :-))를 보유하고있는 대부분의 테이블에 “이름”열이있는 것을 좋아합니다. 이 구조는 응용 프로그램 자체에 큰 유연성을 제공하며 동일한 방식으로 대량 테이블을 처리 할 수 ​​있습니다. 이것은 매우 강력한 것입니다. 일반적으로 OO 소프트웨어는 데이터베이스 위에 구축되지만 OO 도구 세트는 db 자체에서 허용하지 않기 때문에 적용 할 수 없습니다. 열 ID와 이름을 갖는 것은 여전히 ​​좋지 않지만 단계입니다.

선택
i.ID, 송장에서 il.ID은 왼쪽 I i.ID = il.InvoiceID에 InvoiceLines 위원장 가입

왜 이렇게 할 수 없습니까?

Select
    Invoices.ID
,   InvoiceLines.ID
From
    Invoices
    Left Join InvoiceLines
        on Invoices.ID = InvoiceLines.InvoiceID

제 생각에는 이것은 매우 읽기 쉽고 간단합니다. 일반적으로 변수 이름을 i 및 il로 지정하는 것은 좋지 않습니다.


답변

정말 중요하지 않습니다. 모든 명명 규칙에서 유사한 문제가 발생할 가능성이 있습니다.

그러나 쿼리를 작성할 때마다 테이블 정의를 볼 필요가 없도록 일관성을 유지하는 것이 중요합니다.