2008-10-17 8 views
3

최근 몇 가지 질문에서 열 이름을 지정하는 방법에 대해 설명하고 있지만 열 이름에 외래 키 및 기본 키의 개념을 포함시키는 개념을 발견 한 것에 놀랐습니다. 그건 내가 계획의이 종류를 사용하는 데이터베이스 시스템에서 일한 적이 고백해야열 이름에 기본/외래 키 속성을 지정하는 이유

select t1.col_a, t1.col_b, t2.col_z 
from t1 inner join t2 on t1.id_foo_pk = t2.id_foo_fk 

이고, 나는 이점이 무엇인지 궁금하네요. 필자가 보았던 방식으로 시스템의 N 개의 주 테이블을 배웠 으면 이러한 테이블을 사용하여 몇 가지 순서로 더 많은 요청을 작성할 수 있습니다.

개발 과정에서 생산성을 높이려면 어떤 테이블이 중요한 테이블이고 간단한 지류인지 알아야합니다. 많은 양의 컬럼 이름을 메모리에 위탁하고 싶을 것이다. 그리고 기본 작업 중 하나는 두 테이블을 함께 결합하는 것입니다. 학습 노력을 줄이기 위해 할 수있는 가장 쉬운 방법은 두 테이블의 열 이름이 동일한 지 확인하는 것입니다 :

select t1.col_a, t1.col_b, t2.col_z 
from t1 inner join t2 on t1.id_foo = t2.id_foo 

내가 개발자로서, 당신은 많은 것을 상기 할 필요가없는, 멋 부리다 어느 컬럼이 외부 키이고 아무것도 아닌 기본 키인지에 대한 정보를 제공합니다. 호기심이 있다면 스키마를 살펴 보는 것만으로도 충분합니다. 무작위로 볼 때

tx inner join ty on tx.id_bar = ty.id_bar 

... 어느 것이 외래 키인지 아는 것이 중요합니까? 외래 키는 데이터베이스 엔진 자체에서만 중요하므로 참조 무결성을 보장하고 업데이트 및 삭제 중에 올바른 작업을 수행 할 수 있습니다.

어떤 문제가 해결 되었습니까? (나는 이것이 토론 할 수있는 초대장이며, 그렇게 할 자유가 있다고 생각한다. 그러나 동시에 나는 이다.은 진실로 뭔가를 놓친 답을 찾고있다.

답변

6

자식 테이블의 외래 키 열이 상위 테이블의 기본 키 열과 같은 이름이어야한다는 데 동의합니다. 이것은 다음과 같은 구문을 허용합니다 :

SELECT * FROM foo JOIN bar USING (foo_id); 

은 Using 키워드가 열이 두 테이블에 같은 이름으로 존재한다는 것을 가정하고 당신이 동등이 조인하려는. 그것은 더 자세한 속기 등이 사용할 수있는 것이 좋다 :

SELECT * FROM foo JOIN bar ON (foo.foo_id = bar.foo_id); 

단, 당신이 참조하는 기본 키와 같은 외부 키의 이름을 수없는 경우가 있습니다. 예를 들어, 자체 참조가있는 테이블에서 :

CREATE TABLE Employees (
    emp_id INT PRIMARY KEY, 
    manager_id INT REFERENCES Employees(emp_id) 
); 

또한 테이블에는 동일한 상위 테이블에 대해 여러 개의 외래 키가있을 수 있습니다. 내가 열 이름에있는 테이블의 이름을 포함하고 싶지 않아요

CREATE TABLE Bugs (
    ... 
    reported_by INT REFERENCES Accounts(account_id), 
    assigned_to INT REFERENCES Accounts(account_id), 
    ... 
); 

: 그것은 관계의 성격을 설명하는 컬럼의 이름을 사용하는 것이 유용합니다. 필자는 또한 모든 테이블에서 기본 키 열의 이름으로 필수 "id"를 사용하지 않습니다.

7

나는 동의합니다. 이 정보를 칼럼 이름에 넣으면 창간 초기의 창백한 헝가리 식 표기법을 어지럽 힙니다.

-1

나는 당신과 동의 - 나는 많은 기업 환경에서 권장 본 다른 접근 방식 걸릴 : 나는 고객 테이블이 있고 사용자 이름 중 하나였다, 그래서 만약 형식으로

이름 열 TableNameFieldName을 내 필드는 CustomerUserName이라고합니다. 즉, Invoice라고하는 다른 테이블이 있고 고객의 사용자 이름이 외래 키 인 경우 InvoiceCustomerUserName이라고하고, 참조 할 때 Invoice.CustomerUserName이라고하면 즉시 어떤 테이블이 있는지 알려줍니다.

또한이 명명은 사용자가 조인 할 때 열이 들어오는 테이블을 추적하는 데 도움이됩니다.

DBMS의 외부 키와 기본 키의 ACTUAL 이름에만 FK_와 PK_를 사용합니다.

+0

는 않을 것 Invoice.InvoiceCustomerUserName이 될까요? 그리고 이것은 타입 태그보다 더 나쁠 위험이 있습니다 ... Invoice.UserName = Customer.UserName이 나에게 충분히 명확하게 보입니다. –

+0

죄송합니다. 이것은 끔찍한 행동입니다. 단순히 무시 무시한. 테이블 별칭의 필요성을 없애주는 일종의 "영리함"처럼 보입니다. 테이블 이름 앞에 접두어가 붙은 T_와 C_ (보기 및 색인에 접두어가 너무 붙어있는 곳)와 거의 비슷합니다. –

+0

그것은 단지 중복입니다.조인 할 때 테이블 이름을 항상 참조해야합니다. 또한 사용자 이름은 좋은 기본 키가 아닙니다. 예를 들어, CustomerUserName을 갖는 송장은 UserName을 갖는 송장보다 명확하지만 모두 잘못되었습니다. ..JOIN user ON invoice.userid = user.userid가 매우 명확합니다. – gregmac

0

테이블에 대한 외래 키의 프런트 엔드에 "fk_"을 사용했습니다. 주로 내 가게에서 프로젝트 용 DB를 개발할 때 직선으로 유지하는 데 도움이 되었기 때문입니다. 과거 DB 작업을하지 않았기 때문에 이것이 도움이되었습니다. 뒤늦은 지경에서, 아마 그럴 필요는 없었지만, 3 개의 문자가 일부 열 이름에 붙여져 있었기 때문에 나는 그것을 땀을 내지 않았다.

DB 응용 프로그램을 작성하는 데있어 새로운 경험으로, 노련한 DB 개발자를 떨쳐 버릴 수있는 몇 가지 결정을 내렸을 수 있습니다. 그러나 외래 키가 실제로 그렇게 큰 거래인지는 잘 모르겠습니다.다시 말하지만,이 문제에 대한 견해 차이는 분명합니다. 필자가 작성하고 작성한 내용을 확실히 받아 들일 것입니다.

좋은 점이 있습니다!

1

기본 키에 id 접미사가있는 tablename 만 사용합니다 (예 : CustomerId 및 다른 테이블의 참조하는 외래 키도 CustomerId라고합니다. 애플리케이션에서 참조 할 때 객체 속성 (예 : Customer.TelephoneNumber, Customer.CustomerId 등

+0

고객이 고객이 될 수없는 이유는 무엇입니까? 그런 다음 CustomerId 열이있는 테이블에는 고객과의 외래 키 관계가 명확하게 있습니다. –

+1

어떻게 중복되는지 생각할 수 있지만, Customer.Id = Order.CustomerId가 아닌 Customer.CustomerId = Order.CustomerId가있는 것이 좋습니다. –

5

저는 SQL 데이터베이스로 개발해온 20 년이 지난 지금 대부분의 제안을지지했습니다. 저는 당황 스럽습니다. 그들 대부분은 예상되는 혜택을 거의 또는 전혀 제공하지 못했고 목에 통증이있었습니다.

스키마를 사용하는 데 몇 시간 이상을 할애 할 때마다 가장 중요한 테이블과 해당 컬럼을 매우 빨리 익숙하게했습니다. 일단 그것이 몇 달에 도착하면, 나는 내 머리 속에 모든 것을 가지고 있습니다.

누구가이 설명에 누구입니까? 어쨌든 디자인을 몇 분 밖에 쓰지 않는 사람은 아무 것도 심각하게 다루지 않을 것입니다. 산스크리트어로 열 이름을 지정하면 장시간 작업을 계획하는 사람이 배울 것입니다.

기본 키를 무시하면 "id"만큼 간단한 것이 기본 키로 충분하지 않고 외래 키는 "_id"로만 표시되는 이유가 없습니다.

일반적인 조인 조건은 customer.id = order.customer_id이됩니다. 두 테이블 사이에 하나 개 이상의 협회, 차라리 등 "parent_person_id"보다 "child_id"를, 테이블 이름 대신 연결을 사용하기 때문에 아마도 "PARENT_ID을"경사 될 것입니다 존재