왜 int를 조회 테이블의 기본 키로 사용합니까?

조회 값을 기본 키 (대부분의 경우 문자열)로 사용하는 대신 왜 int를 조회 테이블의 기본 키로 사용 해야하는지 알고 싶습니다.

int 대신 nvarchar (50)을 사용하면 많은 레코드가있는 테이블에 연결된 경우 더 많은 공간을 사용한다는 것을 알고 있습니다.

반면에 조회 값을 직접 사용하면 기본적으로 조인을 수행하지 않아도됩니다. 조인이 항상 필요한 경우 이것이 크게 절약 될 것이라고 상상할 수 있습니다 (우리는 웹 응용 프로그램에서 작업하므로 상당히 중요합니다).

"표준 작업"이외의 int 기본 키 (특히 조회 테이블)를 사용하면 어떤 이점이 있습니까?

귀하의 질문에 대한 답변은 물리적이 아니라 논리적입니다. 비즈니스 가치에 따라 귀하가 찾는 가치가 변경 될 수 있습니다. 예를 들어 이메일 주소로 고객을 색인하는 경우 이메일 주소가 변경되면 어떻게됩니까? 분명히 이것은 모든 조회 테이블에 적용되지는 않지만 전체 응용 프로그램에서 동일한 방식으로 수행하면 코드를 간단하게 만들 수 있다는 이점이 있습니다. 모든 것이 내부에서 정수 → 정수 관계라면 커버됩니다.

Sandy에 대한 의견을 읽으십시오.이 경우 아마도 외래 키 / 조회 테이블이 아닌 Check Constraint입니다 .

create table icecream (flavour varchar(10))
go
alter table icecream add constraint ck_flavour check (flavour in ('Orange', 'Pista', 'Mango'))
go
insert into icecream (flavour) values ('Orange')
go
insert into icecream (flavour) values ('Vanilla')
go

이것을 실행하면 다음을 얻습니다.

(1 row(s) affected)
Msg 547, Level 16, State 0, Line 1
The INSERT statement conflicted with the CHECK constraint "ck_flavour". The conflict occurred in database "GAIUSDB", table "dbo.icecream", column 'flavour'.
The statement has been terminated.

이는 효율적인 고성능 방법이지만 새로운 특징을 추가하면 코드가 변경된다는 단점이 있습니다. 응용 프로그램에서 수행하지 않는 것이 좋습니다.이 DB에 연결하는 모든 응용 프로그램에서 수행해야하기 때문에 유효성 검사를 수행하는 데 단일 코드 경로 만 있기 때문에 가장 깨끗한 디자인입니다.

"조회 값을 직접 사용"– 실제 조회 테이블의 목적과 모순되는 비트. 왜 그런 테이블을 유지하고 있습니까? 조회가 아닌 경우
귀하의 질문을 오해했을 수 있습니다. 다음은 msdn 의 조회 테이블 정의입니다.

찾아보기 테이블은 다른 테이블의 외래 키 필드 값을 기반으로 한 테이블의 정보를 표시하는 데 사용됩니다. 예를 들어 영업 데이터베이스의 주문 테이블을 고려하십시오. Orders 테이블의 각 레코드에는 주문한 고객을 나타내는 CustomerID가 포함됩니다. CustomerID는 Customers 테이블의 고객 레코드를 가리키는 외래 키입니다. Orders 테이블에서 주문 목록을 표시 할 때 CustomerID가 아닌 실제 고객 이름을 표시 할 수 있습니다. 고객 이름이 customers 테이블에 있고 Orders 테이블의 데이터를 표시하므로 주문 레코드의 CustomerID 값을 가져 와서 해당 값을 사용하여 관계를 탐색하고 더 많은 값을 리턴하는 찾아보기 테이블을 작성해야합니다. 읽을 수있는 고객 이름.

조회 테이블의 목적을 설명 할 수 있습니까? 다음과 같은 정적 데이터를 저장하는 데 사용되며 이러한 레코드는 다른 테이블 레코드의 입력이 아닙니까?

풍미 테이블

Orange  
Pista  
Mango

위의 상황이라면 조회 테이블을 사용하지 않는 것이 좋습니다. 아마도 웹 응용 프로그램에서 이러한 목록 값을 하드 코딩하십시오. 이렇게하면 불필요한 데이터베이스 쿼리를 피할 수 있습니다.

'특히 룩업 테이블에 대해'질문을 검증했기 때문에 대답은 '공간 절약'으로 단순화되었습니다.

한정자를 제거하면 질문이 '왜 자연 키보다 대리 키를 사용합니까?'가됩니다. 대리 키를 지원하기 위해 다음을 작성 했습니다.

"더 넓은 복합 키 대신 하나의 정수 값을 마이그레이션하면 많은 이점이 있습니다. 이는 물리적 모델 전체에 걸쳐 뛰어난 일관성을 제공하며, 복합 키 마이그레이션과 비교할 때 비용보다 많은 공간을 절약하고 I / O를 줄입니다. 특히 또한 모델과 쿼리 조인에 대한 이해를 단순화합니다. "

이것이 "표준적인 일이되었다"는 이유입니다. 불행히도 이중 제품은 사람들이 대리 키를 던지고 후보 키가 무엇인지 생각하지 않는다는 것입니다. 그러나 지금 우리는 귀하의 질문에서 벗어납니다 :)

내가 항상 사용하는 이유 중 하나는 누군가 오렌지 대신 룩업 테이블에서 값을 잘못 입력 한 경우 룩업 테이블의 값을 변경하는 것이 훨씬 쉽다는 것입니다.

기본 키 번호가있는 조회 테이블은 조회 테이블에서 값만 변경하면됩니다.

기본 키로 값을 사용하는 룩업 테이블은 룩업 테이블과 사용 된 기본 테이블의 모든 레코드에서 변경해야합니다.

ID를 정의 할 때 고유성을 보장 할 수도 있습니다. 그러나 예를 들어 전자 메일과 같은 고유 식별자로 전자 메일을 가져 오면 고유성에 대한 책임을 신뢰할 수없는 3 차 측으로 옮깁니다.