데이터베이스 테이블의 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.table2idid 필드로 tablenameID를 사용하면 이런 종류의 우발적 인 실수가 발생할 가능성이 훨씬 적고 찾기가 훨씬 쉽습니다.
join table2 on table1.table1id = table2.table1id. 당신의 추론은 당신이 id를 사용한다면, 어쨌든 테이블의 이름이 ID 앞에 있다는 것을 제외하고는 괜찮습니다. join table2 on table1.id = table2.table1id... 그것은 장황하고 중복되지 않으며, 방금 언급 한 중복을 방지하기 위해 모호한 별칭을 강요하지도 않습니다. 제 생각에는 SQL 개발의 골칫거리입니다.
Name테이블에 필드 가있는 경우 Table1Name해당 필드와 동일한 문제가 발생하지 않도록 변경해야 합니까? 같은 이유로 모든 열 앞에 테이블 이름을 붙여야합니까? 옳지 않은 것 같습니다.
나는 항상 ID 열에 대해 TableName + ID를 선호하고 외래 키에 대해 TableName + ID를 선호했습니다. 이렇게하면 모든 테이블이 id 필드에 대해 동일한 이름을 가지며 중복 된 설명이 없습니다. 모든 테이블에 동일한 기본 키 필드 이름이 있기 때문에 이것은 나에게 더 간단 해 보입니다.
테이블을 조인하고 어떤 Id 필드가 어떤 테이블에 속하는지 알지 못하는 한, 제 생각에는이 상황을 처리하기 위해 쿼리를 작성해야합니다. 내가 일하는 곳에서는 항상 테이블 / 테이블 별칭이있는 명령문에서 사용하는 필드보다 우선합니다.
최근에 우리 회사에서 이것에 대해 괴짜 싸움이있었습니다. LINQ의 출현은 중복 된 tablename + ID 패턴을 내 눈에 훨씬 더 어리석게 만들었습니다 . 가장 합리적인 사람들은 FK 를 구별하기 위해 테이블 이름을 지정해야하는 방식으로 SQL을 작성하는 경우 입력 비용을 절약 할 수있을뿐만 아니라 SQL에 명확성을 추가하여 PK 와 FK를 명확하게 볼 수있는 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로 지정하는 것은 좋지 않습니다.
방금 "ID"(외래 키의 TableNameID로 참조되는 핵심 테이블에서) 만 사용하는 곳에서 작업을 시작했으며 이로 인해 직접 발생하는 두 가지 프로덕션 문제를 이미 발견했습니다.
한 경우 쿼리는 "... where ID in (SELECT TransID FROM OtherTable ..."대신에 "... where ID in (SELECT ID FROM OtherTable ...")를 사용했습니다.
잘못된 문장이 "... where TransID in (SELECT OtherTableID from OtherTable ..."을 읽었을 때 완전하고 일관된 이름이 사용 되었다면 더 쉽게 발견 할 수 없었을 것입니다. 그래서.
다른 문제는 코드를 리팩토링 할 때 발생합니다. 이전에 쿼리가 코어 테이블을 벗어난 반면 임시 테이블을 사용하는 경우 이전 코드는 "... dbo.MyFunction (t.ID) ..."을 읽습니다. 변경되지 않은 경우 "t"는 핵심 테이블 대신 임시 테이블을 사용하면 오류가 발생하지 않고 잘못된 결과 만 발생합니다.
불필요한 오류를 생성하는 것이 목표라면 (일부 사람들은 충분한 작업이 없습니까?) 이런 종류의 명명 규칙이 좋습니다. 그렇지 않으면 일관된 이름을 지정하는 것이 좋습니다.
나는 개인적으로 (위에서 언급했듯이) PK 의 Table.ID 와 FK의 TableID 를 선호 합니다. . 심지어 (나를 쏘지 마십시오) Microsoft Access는 이것을 권장합니다.
그러나 일부 생성 도구는 ID 를 포함 하여 단어에 'ID' 를 포함하는 모든 열 이름을 연결하는 경향이 있기 때문에 PK에 대해 TableID를 선호한다는 사실도 알고 있습니다 !!!
쿼리 디자이너조차도 Microsoft SQL Server에서이 작업을 수행합니다 (그리고 생성하는 각 쿼리에 대해 열 ID의 모든 테이블에서 불필요한 새로 생성 된 모든 관계를 제거하게됩니다).
내 내부 OCD가 싫어하는 것처럼 TableID 규칙을 사용합니다. Data BASE 라는 것을 기억합시다.앞으로 많은 많은 응용 프로그램의 기반이 될 것이기 때문에 . 그리고 모든 기술은 명확한 설명 스키마로 잘 표준화 된 이점이 있어야합니다.
사람들이 TableName, TableDescription 등을 사용하기 시작할 때 선을 그리는 것은 당연합니다. 제 생각에는 컨벤션은 다음을 수행해야합니다.
테이블 별칭 : 전체 테이블 이름, 단일화. 전의.
SELECT Employee.*, eMail.Address
FROM Employees AS Employee LEFT JOIN eMails as eMail on Employee.eMailID = eMail.eMailID -- I would sure like it to just have the eMail.ID here.... but oh well[최신 정보]
또한이 스레드에는 "종류의 관계"또는 역할로 인해 중복 된 열에 대한 유효한 게시물이 있습니다. 예를 들어, Store에 EmployeeID 가 있으면 스쿼트를 알 수 있습니다. 그래서 때때로 Store.EmployeeID_Manager 와 같은 일을 합니다. 확실히 그것은 조금 더 크지 만, 사람들은 ManagerID 테이블 이나 EmployeeID 가 거기에서하는 일 을 찾으려고 애 쓰지 않을 것 입니다. 쿼리가 WHERE이면 다음과 같이 단순화합니다. SELECT EmployeeID_Manager as ManagerID FROM Store
User.UserId프로그래밍에 입력하는 것은 좀 이상합니다.
공식 데이터 사전의 관점에서 살펴보면 데이터 요소의 이름을 invoice_ID. 일반적으로 데이터 요소 이름은 데이터 딕셔너리에서 고유하며 이상적으로는 전체적으로 동일한 이름을 갖지만 컨텍스트에 따라 추가 한정 용어가 필요할 수 있습니다 (예 : 명명 된 데이터 요소 employee_ID가 조직도에서 두 번 사용될 수 있으므로 다음과 같이 한정됨) supervisor_employee_ID그리고 subordinate_employee_ID각각.
분명히 명명 규칙은 주관적이며 스타일의 문제입니다. ISO / IEC 11179 지침이 유용한 출발점이라고 생각합니다.
DBMS의 경우 테이블을 항목 모음 (예 : cofig 테이블, 상수 테이블 등 하나의 행만 포함하는 항목 제외), 예를 들어 my employee_ID가 키인 테이블 이름이으로 지정 Personnel됩니다. 그래서 당장 TableNameID대회가 저에게 효과가 없습니다.
나는 TableName.ID=PK TableNameID=FK큰 데이터 모델에 사용 된 스타일을 보았고 약간 혼란 스럽다고 말해야한다. 나는 식별자의 이름이 전체적으로 동일한 것을 선호한다. 즉 어떤 테이블에 나타나는지에 따라 이름을 변경하지 않는다. 앞서 언급 한 스타일은 모든 테이블에 IDENTITY(자동 증가) 열을 추가 하면서 외래 키에서 자연 키와 복합 키를 분리 하는 상점에서 사용되는 것으로 보입니다 . 이러한 상점에는 공식적인 데이터 사전이 없거나 데이터 모델에서 빌드하지 않는 경향이 있습니다. 다시 말하지만, 이것은 단지 스타일의 문제이며 개인적으로 구독하지 않는 문제입니다. 그래서 궁극적으로 그것은 나를위한 것이 아닙니다.
즉, 테이블 이름이 컨텍스트를 제공 할 때 열 이름에서 한정자를 가끔 삭제하는 경우를 볼 수 있습니다. 예를 들어 이름 employee_last_name이 지정된 요소 가 단순히 테이블 last_name에 포함될 수 있습니다 Personnel. 여기에 이론적 근거는 도메인이 '사람의 성과 이름'이고 가능성이 될 것입니다 UNION와 에드 last_name열 에서 오히려 외래 키로 사용이 아닌 다른 테이블 에서 , 난 그냥 내 마음을 바꿀 수 ... 다음 다시 다른 테이블 있지만, 때로는 결코 말할 수 없습니다. 데이터 모델링은 예술이고 과학입니다.
일관성이있는 한 "ID"로 무엇이든 사용할 수 있다고 생각합니다. 테이블 이름을 포함하는 것이 중요합니다. Erwin과 같은 모델링 도구를 사용하여 명명 규칙과 표준을 적용하는 것이 좋습니다. 이렇게하면 쿼리를 작성할 때 테이블간에 존재할 수있는 관계를 쉽게 이해할 수 있습니다.
첫 번째 문장이 의미하는 것은 ID 대신 'recno'와 같은 다른 것을 사용할 수 있다는 것입니다. 따라서이 테이블의 PK는 invoice_recno 등입니다.
건배, 벤
내 투표는 테이블 ID에 대한 InvoiceID입니다. 또한 외래 키로 사용될 때 동일한 명명 규칙을 사용하고 쿼리에서 지능형 별칭 이름을 사용합니다.
Select Invoice.InvoiceID, Lines.InvoiceLine, Customer.OrgName
From Invoices Invoice
Join InvoiceLines Lines on Lines.InvoiceID = Invoice.InvoiceID
Join Customers Customer on Customer.CustomerID = Invoice.CustomerID물론, 다른 예보다 깁니다. 하지만 웃으세요. 이것은 후손을위한 것이며 언젠가는 불쌍한 주니어 코더가 당신의 걸작을 바꿔야 할 것입니다. 이 예에서는 모호성이 없으며 쿼리에 추가 테이블이 추가됨에 따라 자세한 내용에 감사 할 것입니다.
각 키에 고유 한 이름 (예 : "invoices.id"대신 "invoices.invoice_id")을 지정하면 걱정없이 "자연 조인"및 "사용"연산자를 사용할 수 있습니다. 예
SELECT * FROM invoices NATURAL JOIN invoice_lines
SELECT * FROM invoices JOIN invoice_lines USING (invoice_id)대신에
SELECT * from invoices JOIN invoice_lines
ON invoices.id = invoice_lines.invoice_idSQL은 더 장황하지 않고 충분히 장황합니다.
일관성을 유지하기 위해 내가하는 일은 (테이블에 ID로 사용되는 단일 열 기본 키가있는 경우) 테이블의 기본 키 이름을 지정하는 것 Table_pk입니다. 해당 테이블 기본 키를 가리키는 외래 키가있는 곳이면 어디에서나 column을 호출합니다 PrimaryKeyTable_fk. 이렇게하면 Customer_pkCustomer 테이블과 Customer_fkOrder 테이블에 A가있는 경우 Order 테이블이 Customer 테이블의 항목을 참조하고 있음을 알 수 있습니다.
나에게 이것은 특히 더 쉽게 읽을 수 있다고 생각하는 조인에 대해 의미가 있습니다.
SELECT *
FROM Customer AS c
INNER JOIN Order AS c ON c.Customer_pk = o.Customer_fkFWIW, 우리의 새로운 표준 (새로운 프로젝트마다 "진화"를 의미합니다)은 다음과 같습니다.
pk_ 접두사는 기본 키를 의미합니다._id 접미사는 정수, 자동 증가 ID를 의미합니다.fk_ 접두사는 외래 키를 의미합니다 (접미사가 필요하지 않음)._VW 뷰 접미사is_ 부울의 접두사따라서 이름이 NAMES 인 테이블 에는 다음과 같이 정의 된 필드 pk_name_id, first_name, last_name, is_alive,및 fk_company뷰 가있을 수 있습니다 LIVING_CUSTOMERS_VW.
이름, 성 선택 CONTACT.NAMES에서 WHERE (is_alive = 'True')
다른 사람들이 말했듯이, 일관성이 있고 의미를 불필요하게 난독 화하지 않는 한 거의 모든 계획이 작동합니다.
나는 평범한 이드 이름이 싫다. 항상 invoice_id 또는 그 변형을 사용하는 것이 좋습니다. 나는 항상 내가 필요할 때 어떤 테이블이 id에 대한 권위있는 테이블인지 알고 있지만 이것은 나를 혼란스럽게합니다.
SELECT * from Invoice inv, InvoiceLine inv_l where
inv_l.InvoiceID = inv.ID
SELECT * from Invoice inv, InvoiceLine inv_l where
inv_l.ID = inv.InvoiceLineID
SELECT * from Invoice inv, InvoiceLine inv_l where
inv_l.ID = inv.InvoiceID
SELECT * from Invoice inv, InvoiceLine inv_l where
inv_l.InvoiceLineID = inv.ID 가장 나쁜 것은 당신이 언급 한 믹스입니다. 완전히 혼란 스럽습니다. 나는 가장 많이 사용되는 ID 중 하나를 제외하고 거의 항상 foo_id 인 데이터베이스로 작업해야했습니다. 그것은 완전히 지옥이었습니다.
나는 DomainName을 선호 해 || '신분증'. (예 : DomainName + ID)
DomainName은 종종 TableName과 동일하지만 항상 그런 것은 아닙니다.
ID 자체의 문제는 모두 확장되지 않는다는 것입니다. 각각 ID라는 첫 번째 열이있는 약 200 개의 테이블이 있으면 데이터가 모두 똑같이 보이기 시작합니다. 항상 테이블 이름으로 ID를 한정하면 조금 도움이되지만 그다지 많지는 않습니다.
DomainName 및 ID를 사용하여 외래 키와 기본 키의 이름을 지정할 수 있습니다. 외래 키가 참조하는 열의 이름을 따서 명명되면 니모닉 지원이 될 수 있습니다. 공식적으로, 참조 무결성 제약이 참조를 설정하므로 외래 키의 이름을 참조하는 키에 연결할 필요가 없습니다. 그러나 쿼리 및 업데이트를 읽을 때 매우 편리합니다.
가끔 DomainName || 동일한 테이블에 동일한 이름을 가진 두 개의 열이 있기 때문에 'ID'를 사용할 수 없습니다. 예 : Employees.EmployeeID 및 Employees.SupervisorID. 그런 경우에는 RoleName을 사용합니다 || 예에서와 같이 'ID'.
마지막으로 가능한 한 합성 키보다 자연 키를 사용합니다. 자연 키를 사용할 수 없거나 신뢰할 수없는 상황이 있지만 자연 키가 올바른 선택 인 상황이 많이 있습니다. 그런 경우에는 자연 키에 자연스럽게 이름을 부여했습니다. 이 이름에는 종종 'ID'라는 글자도 없습니다. 예 : OrderNo 여기서 No는 "Number"의 약어입니다.
Interakt 사이트의 명명 규칙 을 참조하여 테이블 및 열 명명 체계를 잘 고려하십시오. 이 방법은 각 테이블 ( _prd제품 테이블 또는 _ctg범주 테이블) 에 대한 접미사를 사용 하고 주어진 테이블의 각 열에이를 추가합니다. 따라서 제품 테이블의 ID 열 id_prd은 데이터베이스에서 고유하므로 고유합니다.
한 단계 더 나아가 외래 키를 이해하는 데 도움이됩니다. 카테고리 테이블을 참조하는 제품 테이블의 외래 키는 idctg_prd그것이 속한 테이블 ( _prd접미사)과 참조하는 테이블 (카테고리) 이 분명해집니다. .
장점은 다른 테이블의 ID 열에 대한 모호성이 없으며 열 이름으로 쿼리가 참조하는 열을 한 눈에 알 수 있다는 것입니다.
기본 키 / 외래 키 명명 규칙 도 참조하십시오.
다음 명명 규칙을 사용할 수 있습니다. 결함이 있지만 특정 문제를 해결합니다.
invInvoice-, InvoiceLines-).invlinv_id.invl_idinvl_inv_id이름에 사용 하십시오.이렇게 말할 수 있습니다
SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id