여러 열 기본 키를 사용하거나 새 열을 추가해야합니까?

15

현재 데이터베이스 디자인에서는 여러 열 기본 키를 사용하여 각 항목에 임의의 키를 할당하는 추가 열을 만드는 대신 기존 데이터 (어쨌든 고유 한)를 사용합니다. 나는 이것이 허용된다는 것을 알고 있지만 이것이 조심스럽게 사용하고 피할 수있는 연습인지 궁금해하고 있었다 (C의 goto와 매우 비슷 함).

그렇다면이 접근법에서 볼 수있는 단점 중 하나 또는 단일 열 키를 원할 수있는 이유는 무엇입니까?

database-design

— 코바
소스

2

나는 몰라, 나는 이것이 더 좋을 것이라고 생각한다.

— FrustratedWithFormsDesigner

2

@FrustratedWithFormsDesigner SO로 갈 수는 있지만 여기서도 효과가 있다고 생각합니다. 질문의 초점은 "어떻게 X를합니까?"보다는 "이 접근법의 장단점은 무엇입니까?"

— Adam Lear

@Anna Lear ♦ : 코딩에 직접적이고 명확한 영향을 미치는 디자인 결정에 대한 "장단점"이므로 더 좋은 곳이라고 생각합니다.

— FrustratedWithFormsDesigner

8

일반적으로 다중 열 기본 키가있는 테이블이있는 경우 자체 테이블로 승격 된 조인 테이블 (다 대다)의 결과이므로 고유 한 기본 키가 필요합니다. 모든 조인 테이블이 기본적으로 엔터티가되어야한다고 주장하는 많은 사람들이 있지만, 그것은 다른 날에 대한 토론입니다.

가상의 다 대 다 관계를 살펴 보자.

학생 * --- * 수업

(학생은 여러 수업에 참여할 수 있으며, 수업에는 여러 학생이있을 수 있습니다).

이 두 테이블 사이에는 StudentClass (또는 작성 방법에 따라 ClassStudent)라는 접합 테이블이 있습니다. 때때로, 당신은 학생이 수업에있을 때와 같은 것을 추적하고 싶어합니다. 따라서 StudentClass 테이블에 추가합니다. 이 시점에서 StudentClass는 고유 한 엔티티가되었으며 등록과 같이 인식 할 수있는 이름을 부여해야합니다.

학생 1 --- * 등록 * --- 1 수업

(학생은 많은 등록을 가질 수 있으며, 각 등록은 한 수업에 대한 것입니다 (또는 반이 많은 등록을 가질 수있는 반대 방향으로 가고, 각 등록은 한 학생에 대한 것입니다).

이제 지난해 화학 101 수업에 몇 명의 학생이 등록 했습니까? 아니면 Acme University에 다니면서 John Doe 학생은 어떤 수업에 등록 했습니까? 별도의 기본 키 없이도 가능했지만 등록을위한 기본 키가 있으면 이러한 등록에 대해 더 쉬운 쿼리를 얻을 수 있습니다 (ID 별).

엔터티가 PK를받을 자격이 있는지 여부를 결정하면 해당 엔터티에 대해 얼마나 많은 쿼리 (또는 조작)를 수행 할 것인지가 결정됩니다. 예를 들어, 수업 시간에 학생에게 완료된 과제를 첨부하려고한다고 가정 해 보겠습니다. 이 엔터티를 할당 할 논리적 장소 (지정)는 등록 엔터티에 있습니다. 등록하면 고유 한 기본 키로 할당 쿼리가 더 간단 해집니다.

— 마이클 브라운
소스

1

따라서 StudentClass 테이블에 추가합니다. 이 시점에서 StudentClass는 고유 한 엔티티가되었으며 등록과 같이 인식 할 수있는 이름을 부여해야합니다. 그것은 매우 간단한 일이지만 이것을 수행하는 데 많은 가치가 있습니다!

— Botis

8

별도의 ID 열을 갖는 것이 좋습니다. 데이터베이스 테이블에서 무언가를 얻으려면 다음을 수행하는 것이 더 쉽습니다.

SELECT whatever FROM table WHERE id=13

col1 = 'val1'AND col2 = 'val2'AND col3 = 'val3'어디서나 테이블에서 SELECT보다

예를 들어, 웹 애플리케이션에서 다음과 같은 URL로 변환됩니다.

www.somewebsite.com/somepage.php?id=13

또는 이와 같이 :

www.somewebsite.com/somepage.php?col1=val1&col2=val2&col3=val3

— 적외선
소스

4

그리고 그것은 당신이 아이디에 링크 할 수 있습니다 때 대신 여러 열의, 관련 테이블을 추가하는 것이 훨씬 쉽다

— CaffGeek

3

죄송합니다.이 시점에서 나는 -1이어야합니다. A) 흑백이 아닙니다. ID 열을 추가하면 언제 어디서 언제 새 ID를 생성 할 것인지와 같은 부정적인 요소가 나타납니다. 또한 추가 조인 또는 SELECT쿼리 가 발생할 수 있습니다 . 그리고, B)는 , 당신이) 나쁜 프레임 워크를 사용하여 작업하는 경우가 아니면이 실제로 (URL 요구 사항의 모든 종류의 원인이 어떻게 어떤 생각이 없습니다. 내 URL에는 쿼리 문자열이 포함 ?id=13되어 있지 않습니다 ?col1=val1&col2=val2&col3=val3.

— Nicole

2

@renesis :이 사이트에는 URL에있는 고유 한 질문과 사용자가 있습니다. 그러나 특정 데이터는 변경되지 않으므로 다소 특별한 경우입니다.

— Michael K

1

@Renesis, 대부분 (아마도) 현대 db에는 자동으로 안전하게 ID를 생성하고 SQL 쿼리 또는 라이브러리 함수 호출을 통해 다시보고 할 수있는 auto_increment 정수 열 유형이 있습니다. 또는 분산 환경에서는 큰 임의 해시를 사용합니다. 일부 DB 는 테이블에 이미 ID가 없으면 숨겨진 ID 열을 만듭니다 .

— GrandmasterB

@Michael-ID가 URL에 없다고 말하지 않았습니다. 물론입니다. 데이터 행을 나타내는 URL이 있다면 해당 데이터에 고유 ID가 있어야합니다. URL의 다른 부분이 이미 멀티 키의 다른 부분을 제공하지 않는 한. @GrandmasterB MySQL (Oracle 및 SQL Server도 지원)을 사용하는 지난 6 년 동안 근무한 두 회사 중 어느 것도 자동 증분이나 대규모 임의 해시를 사용할 수 없었습니다.

— Nicole

8

기본적으로 대리 키 또는 자연 키를 사용해야하는지 묻습니다 (이 경우 복합 자연 키 처럼 들립니다 ). 다음은 훌륭한 기사입니다. http://www.agiledata.org/essays/keys.html

대리 키는 DB의 수명 동안 관리를 단순화하기 때문에 선호합니다. 키 변경이 의미가 바뀌는 의미에 대해 걱정할 필요가 없습니다. 이는 절대 발생하지 않아야하지만 인간이 관여하는 실제 시스템에서는 발생하지 않습니다. 그러나 DB에 많은 "조회"테이블이있는 경우 (예 : 기본적으로 키 : 값 쌍인 테이블) 대리 키는 의미있는 결과를 얻기 위해 해당 테이블을 쿼리에 조인해야하기 때문에 번거로울 수 있습니다.

예를 들어 주소와 국가라는 두 개의 엔터티가 있다고 가정합니다.

관계 : 주소 * ----- 1 국가
국가 항목은 기본적으로 키 : 값 쌍입니다 (예 : 미국 : 미국, CA : 캐나다, MX : 멕시코 등).
미국의 모든 주소에 대해이 구조를 쿼리하려면

select * from Address where CountryCode = 'US'

서로 게이트 키를 사용하여 동일한 쿼리를 수행하려면

select Address.* from Address join Country on Address.CountryID = Country.ID where Country.Code = 'US'

자연 키가 너무 자주 변경되지 않는다고 확신하면 조회 테이블에 대한 자연 키와 다른 모든 항목에 대한 자연 키를 위임하는 것이 편안합니다.

— 커티스 바트
소스

5

데이터에 액세스하는 방법에 따라 다릅니다. 부분 키 조회를 많이 수행하는 경우 (세 개의 키 중 두 개만 기준으로 레코드를 선택하는 경우) 다중 파트 키를 유지해야합니다. OTOH, 다른 테이블과 1 : 1 관계가 많으면 대리 키를 갖는 것이 더 합리적입니다.

— TMN
소스

1

나는 항상 각 테이블에 대한 대리 기본 키를 갖고 싶습니다. 그러나 내가 들었던 이것을 시행해야 할 "고난"이유는 많지 않습니다.

내가 여러 열의 자연 키를 물린 적이 있었을 때 ORM을 사용했습니다. Linq To Entities를 사용하는 다중 열 기본 키에 문제가있는 경우가 있습니다.

— 마이크 엠
소스

1

절대로 말하지 말고 4 열에 합류하는 것은 고통입니다. 지능적인 데이터가있는 열이 많을수록 해당 값이 변경 될 가능성이 높아집니다. 계단식 업데이트로 참조 무결성을 유지하도록 데이터베이스를 설정할 수 있습니다.

고유 한 값을 처리하기 위해 항상 다른 색인을 작성할 수 있습니다.

대부분의 경우 성능은 무시할 수 있지만 대체 키를 사용하거나 사용하지 않고 쿼리를 테스트 할 수 있습니다.

— 제프
소스

0

별도의 키를 요구할만한 이유를 생각해내는 것이 어렵다는 것을 알고 있지만 많은 사람들이 키를 넣었다고 말한 것처럼.

사실 / 세부 정보 테이블을 처리 할 때 도움이되지 않습니다 (특히 스토리지 관련). 정식 예제 로 수량 이 (customer_key, store_key, product_key) 인 판매 팩트 테이블 은 레코드 레벨 키를 갖는 것이 의미가 없습니다.

— 제 큐
소스

0

복합 키가 실제로 중복을 가질 수있는 경우 PK를 자동 증분 int로 설정하면 번거 로움이 줄어 듭니다.

— 폴 나단
소스

0

Ask Tom 에 대해 2002 년으로 돌아가는 좋은 토론이 있습니다 . 오라클 전용이지만 더 넓은 토론은 사용중인 데이터베이스와 관련이 있습니다.

— 리스 깁슨
소스