데이터베이스 테이블의 ID 열 이름 지정
데이터베이스 테이블의 ID 열 이름 지정에 대한 사람들의 의견이 궁금합니다.
ID 열의 기본 키가있는 송장이라는 테이블이있는 경우 다른 테이블과 충돌하지 않도록 해당 열을 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를 사용하는 경우 조인 구문을 복사하는 경우 (아무도이 작업을 수행하지 않는다고 말하지 않습니다!) 조인 조건에서 코드를 변경하는 것을 잊어 버리면 쉽게 잘못된 조인으로 끝날 수 있습니다.
그래서 당신은 이제
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에 명확성을 추가하여 PK 와 FK를 명확하게 볼 수있는 ID입니다 .
예
직원에서 e LEFT JOIN Customers c ON e.ID = c.EmployeeID
두 가지가 연결되어 있다는 것이 어느 것이 PK 이고 어느 것이 FK 인지 알려줍니다 . 구식 스타일에서는 이름이 잘 붙었 으면 좋겠다는 생각을했습니다.
우리는 사용하지 InvoiceID않습니다 ID. 이는 쿼리를 더 읽기 쉽게 만듭니다 ID. 특히 테이블의 이름을 i.
나는 테이블의 PK가 동의합니다. 나는 테이블의 PK가 동의합니다.
그러나 나는 최근에 더 큰 비중을 둔 한 가지 이유를 추가하고 싶다.
현재 위치에서 우리는 POCO 생성을 사용하는 프레임 워크를 사용하고 있습니다. Id의 표준 명명 규칙을 사용하면 PK는 유효성 검사를 통해 기본 poco 클래스를 상속 할 수 공통 공통 열 이름 집합을 공유하는 테이블에 동일합니다. Tablename + Id를 사용하면 기존 테이블에 기본 클래스를 사용하는 기능이 손상됩니다.
생각할 음식이 있습니다.
정말 중요하지 않습니다. 모든 명명 규칙에서 가능성이 있습니다.
그러나 쿼리가 중요 할 때마다 테이블 정의를 유지하는 것이 중요합니다.
내 선호도는 기본 키의 ID와 외래 키의 TableNameID입니다. 또한 사용자가 읽을 수있는 항목의 식별자 (예 : 이름 :-))를 보유하고있는 대부분의 테이블에 "이름"열이있는 것을 좋아합니다. 이 구조는 응용 프로그램 자체에 큰 유연성을 제공하며 방식으로 대량 테이블을 처리 할 수 있습니다. 이것은 매우 강력한 것입니다. 일반적으로 OO 소프트웨어는 데이터베이스 위에 구축 한 OO 도구 세트는 db 자체에서 허용하지 않기 때문에 적용 할 수 없습니다. 비록 단단하지만 단단하지 않습니다.
선택
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"는 핵심 테이블 대신 임시 테이블을 사용하면 오류가 발생하지 않고 잘못된 결과 만 발생합니다.
불필요한 오류를 생성하는 것이 목표라면 (일부 사람들은 충분한 작업이 없습니까?), 이런 종류의 명명 규칙이 좋습니다. 그렇지 않으면 일관된 이름을 지정하는 것이 좋습니다.
단순화를 위해 대부분의 사람들은 테이블 ID에 열 이름을 지정합니다. 다른 테이블에 대한 외래 키 참조가있는 경우 조인의 경우 명시 적으로 InvoiceID라고 부릅니다 (예제를 사용하기 위해), 어쨌든 테이블의 별칭을 지정하므로 명시 적 inv.ID는 여전히 inv.InvoiceID보다 간단합니다.
공식 데이터 사전의 관점에서 살펴보면 데이터 요소의 이름을 invoice_ID. 일반적으로 데이터 요소 이름은 데이터 딕셔너리에서 고유하며 이상적으로는 전체적으로 동일한 이름을 갖지만 컨텍스트에 따라 추가 한정 용어가 필요할 수 있습니다. 예를 들어 명명 된 데이터 요소 employee_ID는 조직도에서 두 번 사용될 수 있으므로 다음과 같이 한정됩니다. supervisor_employee_ID그리고 subordinate_employee_ID각각.
분명히 명명 규칙은 주관적이며 스타일의 문제입니다. ISO / IEC 11179 지침이 유용한 출발점이라고 생각합니다.
For the DBMS, I see tables as collections of entites (except those that only ever contain one row e.g. cofig table, table of constants, etc) e.g. the table where my employee_ID is the key would be named Personnel. So straight away the TableNameID convention doesn't work for me.
나는 TableName.ID=PK TableNameID=FK큰 데이터 모델에 사용 된 스타일을 보았고 약간 혼란 스럽다고 말해야한다. 나는 식별자의 이름이 전체적으로 동일한 것을 선호한다. 즉 어떤 테이블에 나타나는지에 따라 이름을 변경하지 않는다. 앞서 언급 한 스타일은 모든 테이블에 IDENTITY(자동 증가) 열을 추가 하면서 외래 키에서 자연 키와 복합 키를 분리 하는 상점에서 사용되는 것 같습니다 . 이러한 상점에는 공식적인 데이터 사전이 없거나 데이터 모델에서 빌드하지 않는 경향이 있습니다. 다시 말하지만, 이것은 단지 스타일의 문제이며 개인적으로 구독하지 않는 문제입니다. 그래서 궁극적으로 그것은 나를위한 것이 아닙니다.
즉, 테이블 이름이 컨텍스트를 제공 할 때 열 이름에서 한정자를 가끔 삭제하는 경우를 볼 수 있습니다. 예를 들어 이름 employee_last_name이 지정된 요소 가 단순히 테이블 last_name에 포함될 수 있습니다 Personnel. 여기에 이론적 근거는 도메인이 '사람의 성과 이름'이고 가능성이 될 것입니다 UNION와 에드 last_name열 에서 오히려 외래 키로 사용이 아닌 다른 테이블 에서 , 난 그냥 내 마음을 바꿀 수 ... 다음 다시 다른 테이블 있지만, 때로는 결코 말할 수 없습니다. 데이터 모델링은 예술이고 과학입니다.
나는 개인적으로 (이 위에 언급 된대로) 선호 Table.ID 에 대한 PK 와 테이블 ID 에 대한 FK . 심지어 (나를 쏘지 마십시오) 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
일관성이있는 한 "ID"에 대해 무엇이든 사용할 수 있다고 생각합니다. 테이블 이름을 포함하는 것이 중요합니다. Erwin과 같은 모델링 도구를 사용하여 명명 규칙과 표준을 적용하여 쿼리를 작성할 때 테이블간에 존재할 수있는 관계를 쉽게 이해할 수 있도록하는 것이 좋습니다.
첫 번째 문장이 의미하는 것은 ID 대신 'recno'와 같은 다른 것을 사용할 수 있다는 것입니다. 따라서이 테이블에는 invoice_recno 등의 PK가 있습니다.
건배, 벤
내 투표는 테이블 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
물론, 다른 예보다 깁니다. 하지만 웃으세요. 이것은 후손을위한 것이며 언젠가는 가난한 주니어 코더가 당신의 걸작을 바꿔야 할 것입니다. 이 예에서는 모호함이 없으며 쿼리에 추가 테이블이 추가됨에 따라 자세한 내용에 감사 할 것입니다.
데이터베이스의 열 이름으로 "InvoiceID"를 사용합니다.
LINQ를 통해 필드를 이름이 지정되지 않은 구조체에 복사하면 구조에서 유일한 ID 인 경우 "ID"라는 이름을 지정할 수 있습니다.
열이 외래 키에서 사용되지 않고 편집 또는 삭제를 위해 행을 고유하게 식별하는 데만 사용되는 경우 이름을 "PK"로 지정합니다.
각 키에 고유 한 이름 (예 : "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_id
SQL은 더 장황하지 않고 충분히 장황합니다.
일관성을 유지하기 위해 내가하는 일은 (테이블에 ID로 사용되는 단일 열 기본 키가있는 경우) 테이블의 기본 키 이름을 지정하는 것 Table_pk입니다. 테이블 기본 키를 가리키는 외래 키가있는 곳이면 어디에서나 column을 호출합니다 PrimaryKeyTable_fk. 이렇게하면 Customer_pk내 고객 테이블과 Customer_fk주문 테이블에가있는 경우 주문 테이블이 고객 테이블의 항목을 참조하고 있음을 알 수 있습니다.
나에게 이것은 특히 더 쉽게 읽을 수 있다고 생각하는 조인에 대해 의미가 있습니다.
SELECT *
FROM Customer AS c
INNER JOIN Order AS c ON c.Customer_pk = o.Customer_fk
FWIW, 우리의 새로운 표준 (새로운 프로젝트마다 "진화"를 의미합니다)은 다음과 같습니다.
- 소문자 데이터베이스 필드 이름
- 대문자 테이블 이름
- 필드 이름에서 단어를 구분하려면 밑줄을 사용하십시오. 코드에서이를 Pascal 대소 문자로 변환하십시오.
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')
다른 사람들이 말했듯이, 일관성이 있고 의미를 불필요하게 난독 화하지 않는 한 거의 모든 계획이 작동합니다.
나는 정확히 당신이 제공하는 이유 때문에 ID 필드 이름에 테이블 이름을 포함하는 데 동의합니다. 일반적으로 이것은 테이블 이름을 포함하는 유일한 필드입니다.
나는 평범한 이드 이름이 싫어. 항상 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"의 약어입니다.
각 테이블에 대해 트리 문자 속기 (예 : Employees => Emp)를 선택합니다.
이렇게하면 숫자 자동 번호 기본 키가 nkEmp 가 됩니다 .
전체 데이터베이스에서 짧고 고유하며 한눈에 그 속성을 정확히 알고 있습니다.
SQL과 내가 사용하는 모든 언어 (주로 C #, Javascript, VB6)에서 동일한 이름을 유지합니다.
Interakt 사이트의 명명 규칙 을 참조하여 테이블 및 열 명명 체계를 잘 고려하십시오. 이 방법은 각 테이블 ( _prd제품 테이블 또는 _ctg범주 테이블) 에 대한 접미사를 사용 하고 주어진 테이블의 각 열에이를 추가합니다. 따라서 제품 테이블의 ID 열 id_prd은 데이터베이스에서 고유하므로 고유합니다.
한 단계 더 나아가 외래 키를 이해하는 데 도움이됩니다. 카테고리 테이블을 참조하는 제품 테이블의 외래 키는 idctg_prd그것이 속한 테이블 ( _prd접미사)과 참조하는 테이블 (카테고리) 이 분명합니다. .
장점은 다른 테이블의 ID 열에 대한 모호성이 없으며 열 이름으로 쿼리가 참조하는 열을 한 눈에 알 수 있다는 것입니다.
기본 키 / 외래 키 명명 규칙 도 참조하십시오.
다음 명명 규칙을 사용할 수 있습니다. 결함이 있지만 특정 문제를 해결합니다.
- 테이블 이름에 짧은 (3-4 자) 별명을 사용하십시오 (예 :
invInvoice-, InvoiceLines-).invl - 해당 별명을 사용하여 테이블의 컬럼 이름을 지정하십시오
inv_id.invl_id - 참조 열의 경우
invl_inv_id이름에 사용 하십시오.
이렇게 말할 수 있습니다
SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id
참고 URL : https://stackoverflow.com/questions/208580/naming-of-id-columns-in-database-tables
'IT' 카테고리의 다른 글
| 모듈로 연산자 (%)는 C #의 다른 .NET 버전에 대해 다른 결과를 제공합니다. (0) | 2020.09.06 |
|---|---|
| Vagrant에서 RAM을 늘리고 호스트해야 할 설정을 설정해야합니까? (0) | 2020.09.06 |
| 마우스를 사용하여 HTML5 Canvas에 그리기 (0) | 2020.09.06 |
| Debian / Ubuntu Docker 컨테이너에 로케일을 설정하는 방법은 무엇입니까? (0) | 2020.09.06 |
| 명령 줄에서 여러 AWS 계정을 사용하는 방법은 무엇입니까? (0) | 2020.09.06 |