기본 키의 데이터 유형을 선택할 때 고려해야 할 사항은 무엇입니까?

Question

새 데이터베이스 테이블을 만들 때 기본 키의 데이터 형식을 선택하기 위해 고려해야 할 요소는 무엇입니까?

Answer 1

불편을 끼쳐 드려 죄송합니다. 관련 질문 (this 및 this을 확인할 수 있음)에 대한 답변이이 문제에 적용될 수 있음을 발견했습니다. 나는 그들에게 조금 모양을 바꿨다 ...

이 문제를 다루는 많은 게시물을 발견 할 수 있으며, 각 선택은 장단점이있다. 이러한 인수는 대개 관계형 데이터베이스 이론 및 데이터베이스 성능을 나타냅니다. 자연 키 항상 여러 가지 이유로 요즘 중 하나,이 작동하지 않을 수 있습니다 동안, 대리 기본 키는 항상 작업 : 필드가 너무 짧은,이 주제에

, 나의 점은 매우 간단합니다 규칙 변경 등이 있습니다.

여기까지는 기본적으로 uniqueIdentifier/surrogate 기본 키 팀의 구성원이며 여기에 제시된 인수와 같은 인수를 이해하고 이해한다고 생각합니다. 여전히 "천연"키가 대리모보다 더 나은 경우를 찾고 있습니다 ...

이 외에도

는이 기본 규칙에 찬성 가장 중요하지만 항상 잊어 인수 중 하나가 코드 표준화 및 생산성 관련이있다 :

나는 테이블을 만들 때마다, 나는 시간을 잃게된다

1. 의 기본 키와 물리적 특성 (유형, 크기) 이러한 특성 내 코드에서 참조 할 때마다 기억
2. 을 식별?
3. 내 PK 선택을 팀의 다른 개발자에게 설명 하시겠습니까?

내 대답은이 모든 질문에 아무 없습니다 :

1. 나는 대리 옵션이 나에게 방탄를 제공 할 때 "가장 좋은 천연 기본 키"를 확인하려고 잃을 시간이 없다 해결책.
2. 코드를 작성할 때 10 자 길이의 문자열 인 내 Table_whatever의 기본 키를 기억하고 싶지 않습니다.
나는 자연 키 길이 협상 내 시간을 잃고 싶지 않아
3. : "당신이하지 않는 이유 당신은 10 필요한 경우도 12 은 안전 측면에있을?". 이 "안전한쪽에" 인자는 정말로 나를 귀찮게합니다. 안전면에 머물고 싶다면 안전하지 않은 쪽에서 정말로 멀지 않은 것을 의미합니다! 대리인을 선택하십시오 : 그것은 방탄입니다!

그래서 아주 기본적인 규칙과 지난 5 년 동안 근무했습니다 각 테이블 (의는 'myTable에'를 부르 자하는) 고유 식별자 유형이다 'id_MyTable'라는 첫 번째 필드가 있습니다. 이 테이블이 필드 조합이 매우 수용 가능한 기본 키를 제공하는 "다 대다"관계를 지원하더라도이 규칙을 고수하기 위해이 'id_myManyToManyTable' 필드를 uniqueIdentifier로 만드는 것을 선호합니다. 아프지 않아.

주요 이점은 코드에서 기본 키 및/또는 외래 키의 사용에 대해 더 이상 신경 쓸 필요가 없다는 것입니다. 테이블 이름을 얻으면 PK 이름과 유형을 알 수 있습니다. 데이터 모델에서 구현 된 링크를 알게되면 테이블에서 사용 가능한 외부 키의 이름을 알 수 있습니다. 당신은 여전히 ​​당신의 표에서 "자연 키"어딘가를 갖고 싶어

는, 나는 당신이 ID_이 기본 키에 대한 접두사

Tbl_whatever 

    id_whatever, unique identifier, primary key 
    code_whatever, whateverTypeYouWant(whateverLengthYouEstimateTheRightOne), indexed 
    ..... 

와 같은 표준 모델 다음을 구축 할 수 조언하고, code_는 "자연"색인 필드에 사용됩니다. 어떤 사람들은 code_ 필드가 유일해야한다고 주장 할 것이다. 이는 사실이며 DDL 또는 외부 코드를 통해 쉽게 관리 할 수 ​​있습니다. "자연스러운"많은 키가 계산되므로 (인보이스 번호) 코드를 통해 이미 생성되었습니다.

내 규칙이 가장 적합하지 않은 것으로 알고 있습니다. 그러나 그것은 매우 효율적인 것입니다! 모두가 그것을 적용한다면, 우리는 예를 들어 이런 종류의 질문에 응답하지 못한 시간을 피할 수 있습니다!

Answer 2

숫자 키를 사용하는 경우 데이터 유형이 테이블이 커질 것으로 예상되는 행 수를 저장할 정도로 커야합니다.

guid를 사용하는 경우 GUID를 저장하는 데 필요한 추가 공간을 고려해야합니까? guid PK에 대한 코딩은 개발자 나 애플리케이션 사용자에게 고통이 될 것입니다.

복합 키를 사용하는 경우 결합 된 열이 항상 고유해야합니까?

Answer 3

대개 저는 항상 정수를 사용합니다. 그러나 여기에 흥미로운 관점이 있습니다.

http://www.codinghorror.com/blog/archives/000817.html

Answer 4

가 나는 생성 된 정수 키를 사용하는 부분입니다. 데이터베이스가 매우 커질 것으로 예상되면 bigint를 사용할 수 있습니다.

일부 사람들은 guids를 사용하고 싶어합니다. 데이터베이스의 여러 인스턴스를 키를 변경하지 않고 병합 할 수 있지만 성능에 영향을 미칠 수 있다는 것이 전문가의 몫입니다.

Answer 5

"자연"키의 경우 열에 적합한 데이터 유형. Artifical (surrogate) 키는 보통 정수입니다.

Answer 6

모두 다릅니다.

a) 고유 한 순차 숫자를 기본 키로 사용하는 것이 좋습니까? 그렇다면 고유 키로 UniqueIdentifier를 선택하면됩니다. b) 비즈니스 요구에 알파 숫자 기본 키가 있어야하는 경우 varchar 또는 nvarchar로 이동해야합니다.

내가 생각할 수있는 두 가지 옵션이 있습니다.

Answer 7

대다수의 시나리오에서는 많은 시나리오가 많은 복제를 필요로하지 않는 한 identity int 기본 키를 사용합니다.이 경우 GUID를 선택할 수 있습니다.

I (거의) 의미있는 키를 사용하지 않았습니다.

Answer 8

가능한 한 자연 키인 기본 키를 사용해보십시오. 예를 들어, 매일 하나의 레코드를 기록한 테이블이 있다면 logdate가 좋은 기본 키가됩니다. 그렇지 않으면 자연 키가 없으면 int를 사용하십시오. 2 십억 개 이상의 행을 사용한다고 생각되면 bigint를 사용하십시오. 어떤 사람들은 GUID를 사용하기를 좋아합니다. GUID는 고유하고, 공간이 부족하지 않으므로 잘 작동합니다. 그러나 그들은 불필요하게 길고 임시 쿼리를 수행하는 경우 입력하기가 어렵습니다.

Answer 9

부동 소수점 숫자를 동일하게 비교할 수 없으므로 부동 소수점 숫자 유형을 사용하지 마십시오.

Answer 10

• 어디에서 생성합니까? 증가하는 숫자는 클라이언트가 생성 한 키에 적합하지 않습니다.
  • 데이터 종속적이거나 독립적 인 키를 원하십니까? (때때로 비즈니스 데이터의 ID를 사용할 수 있으며 항상 유용한 지 여부는 말할 수 없습니다)?
  • DB에서이 유형을 얼마나 잘 인덱싱 할 수 있습니까?

내가 사용하고 uniqueidentifiers (GUID를) 또는 증가 정수 지금까지.

건배 마티아스

Answer 11

당신이 가게에가는 얼마나 많은 데이터 큰 요인입니다. 나는 웹 분석 회사에서 일하고 있으며, 우리는 데이터를 가지고있다. 따라서 페이지 뷰 테이블의 GUID 기본 키는 크기 때문에 우리를 죽일 것입니다.

경험상 뛰어난 성능을 위해 전체 색인을 메모리에 저장할 수 있어야합니다. 안내 인이 쉽게이 문제를 해결할 수 있습니다!

Answer 12

학교에서 가르치는 것이 '자연스러운 키'(예 : 북 데이터베이스의 ISBN)를 사용하거나 2 개 이상의 입력란으로 구성된 기본 키를 사용하는 것을 좋아하지 않습니다. 나는 결코 그것을하지 않을 것이다. 그래서 여기 내 조언이있다 :

• 항상 기본 키에 대해 모든 테이블에 하나의 전용 열이 있습니다. (성능을 필요로하지 않는 경우) 그렇지의 INT
를 증가 할 수있을 때
• 그들은 모두 같은 colomn의 모든 테이블에서 이름, 즉 "ID"또는 "GUID"
• 사용 GUID를 가져야한다

편집 :
좋아요, 제가 선택을 조금 설명해야한다고 생각합니다.

• 전용 열은 기본 키에 대한 모든 테이블을 가로 질러 같은 namend 데, 당신의 SQL-문 (데이터베이스 레이아웃에 익숙하지 않을 수도 있습니다) 다른 사람에 대한 구축하기 쉽게 많은 쉽게한다 이해하기 쉽다. 특히 당신이 많은 JOINS와 그런 것들을 할 때. 특정 테이블에 대한 기본 키를 찾아 볼 필요가 없습니다. 모든 테이블에서 동일하기 때문에 이미 알고 있습니다.

• GUID 대 INT는별로 중요하지 않습니다. GUID의 성능 상한치를 맞추거나 데이터베이스 병합을 수행하지 않는 한, 다른 것과 주요한 문제는 없습니다. BUT 내가 GUID를 선호하는 이유가 있습니다. GUID의 글로벌 고유성은 언젠가 언제나 유용 할 것입니다. 데이터베이스의 일부를 랩톱/휴대 전화와 동기화하거나 심지어 어떤 테이블이 어디에 있는지 알 필요없이 데이터 코드를 찾는 것 같은 GUID의 장점 중 좋은 예가 될 수 있습니다. 제공하십시오. Integer는 한 테이블의 컨텍스트 내에서 레코드를 식별하는 반면 GUID는 모든 레코드를 식별합니다. 모든 너무 자주 현실 세계 중복을 허용 특히, 그 숫자를 사용하는 방법에 대한 규칙을 변경하기 때문에 현실 세계에서 의미가

Answer 13

숫자는, 일반적으로 나쁜 생각, 그리고 당신은있어 네 손에 진짜 난장판이야.

Answer 14

신뢰할 수있는 자연 키를 사용하십시오. 일부 자연 키 소스는 신뢰할 수 없습니다. 몇 년 전, 사회 보장국 (Social Security Administration)은 때로는 두 명의 다른 사람들에게 동일한 SSN을 할당하는 것을 망쳤습니다. Theyv'e는 아마 그것을 지금까지 고쳤습니다.

차량용 VIN 및 책 ISBN을 신뢰할 수 있습니다 (단, ISBN이없는 팜플렛에는 해당되지 않음).

자연 키를 사용하는 경우 자연 키가 데이터 유형을 결정합니다.

자연 키를 신뢰할 수없는 경우 가상 키를 만드십시오. 나는이 목적을 위해 정수를 선호한다. 적절한 확장을위한 충분한 공간을 남겨 둡니다.

Answer 15

매우 편리한 자연 키가 없으면 항상 숫자 유형의 합성 (대리 키) 키를 사용하십시오. 사용 가능한 자연 키가 있더라도 어쨌든 합성 키를 사용하고 자연 키에 고유 한 인덱스를 추가하는 것이 좋습니다. 연방법이 바뀌었을 때 사회 보장 번호를 PK로 사용하는 고급 데이터베이스에 어떤 일이 발생했는지 생각해보십시오. 합성 키로 전환하는 비용은 막대했습니다.

또한 모든 기본 키의 이름을 동일하게 지정하는 것에 동의하지 않아야합니다. "신분증". 이로 인해 쿼리가 더 쉽지 않고 이해하기가 어려워집니다. 기본 키의 이름은 테이블 다음에 지정해야합니다. 예를 들어 employee.employee_id, affiliate.affiliate_id, user.user_id 등이 있습니다.

Answer 16

나는 일반적으로 모든 테이블 (mssql의 rowguid)에 대해 GUID 열 기본 키를 사용합니다. 자연스러운 키가 될 수있는 것은 고유 한 제약 조건을 만듭니다. 일반적인 예는 사용자가 구성하고 고유해야하는 produkt 식별 번호입니다. 인보이스와 같은 시퀀스가 ​​필요한 경우에는 lastnumber 및 직렬화 된 액세스를 보장하는 저장 프로 시저를 유지하는 테이블을 작성합니다. 또는 오라클의 시퀀스 :-) 자연수 키에 대한 "사회 보장 번호"샘플은 등록 과정에서 절대 사용할 수 없으므로 싫어합니다. 더미 숫자를 생성하는 체계가 필요합니다.