sqlserver 메 인 키 디자인 의 주의 점

메 인 키 를 디자인 할 때 다음 과 같은 몇 가 지 를 고려 해 야 한다.1.무의식 적:여기 서 의 미 는 사용자 의 측면 에서 정 의 된 것 이다.이런 무의미 함 은 어느 정도 에 데이터베이스 의 정보 번 거 로 움 을 줄 일 수 있다.흔히 메 인 키 를 내부 표지 라 고 부 릅 니 다.왜 이렇게 부 릅 니까?그 원인 중 하 나 는'내부'입 니 다.내부 란 어느 정도 에 표 기록 을 말 합 니 다.넓 은 범위 에서 볼 때 데이터 베이스 입 니 다.만약 에 디자인 할 때 사용자 에 게 의도 적 인 정 보 를 메 인 키 로 선택 하면그러면 조만간 사용자 가 이 정 보 를 업데이트 하 는 수 요 를 제기 할 것 이다.그러면 너 는 그것 의 정적 에 어 긋 난다.2.정태 성:메 인 키 는 하나의 기록 과 외부 키 의 관 계 를 유일 하 게 표시 하 는 것 을 제외 하고 다른 의 미 를 고려 하지 않 아야 한다.가장 이상 적 인 상 태 는 발생 한 후에 변동 이 없 기 때문에 메 인 키 값 이 발생 한 후에 그 에 게 업데이트 하지 않 는 등 조작 을 고려 해 야 한다.만약 에 업데이트 작업 을 했다 면 적어도 이 정 보 는 사용자 에 게 어느 정도 의미 가 있다 는 것 을 설명 한다 면 당신 은 응당 한 무의식 성에 위배 된다.(데 이 터 를 통합 하 는 등 작업 을 할 때 메 인 키 를 처리 해 야 할 수 있 습 니 다.이렇게 하 는 것 은 데이터 뱅 크 의 완전 성 을 확보 하기 위해 서 입 니 다.-기록 의 유일한 것 이 므 로 이 를 고려 하지 않 습 니 다.)무의식 성 은 종종 그 정태 성 을 결정 할 수 있다.3.간단 성:메 인 키 를 포함 하여 필드 를 구성 하 는 수량 이 적 고 메 인 키 의 단일 필드 저장 유형 이 짧 으 며 일반적으로 성형 을 사용 합 니 다.전자 에 대해 주로 외부 키 와 관련 된 요 소 를 고려한다.후자 에 대해 서 는 주로 성능 을 고려한다.메 인 키 의 간단 함 은 표 의 관련 편리 성과 검색 의 성능 에 큰 도움 이 된다.아래 에 결함 이 있 는'메 인 생산 계획 표'메 인 키 디자인 방안(MsSQL)을 보 세 요

 
--   
CREATE TABLE PP_MPSHeader( 
　　BillNo VARCHAR(20) NOT NULL PRIMARY KEY, 
　　PlanDate DATETIME NOT NULL 
) 
--   
CREATE TABLE PP_MPSBody( 
　　BillNo VARCHAR(20) NOT NULL, 
　　LineNumber SMALLINT NOT NULL, 
　　ProductID INT NOT NULL, 
　　ProductQty DECIMAL(18,2) NOT NULL, 
PRIMARY KEY(BillNo,LineNumber) 
) 
--     
ALTER TABLE PP_MPSBody 
ADD CONSTRAINT FK_PP_MPSHeader_MPSBody FOREIGN KEY(BillNo) REFERENCES PP_MPSHeader(BillNo) 

이것 은 전형 적 인 메 인 키 구조 입 니 다.주 표 는 언제 어떤 번호 의 주 계획 을 내 릴 것 인지,표 에서 기록 한 것 은 이 계획 에서 어떤 제품 을 얼마나 생산 할 것 인지,빌 노 를 통 해 관련 이 있다.사용자 가 메 인 생산 계획 을 내 린 후에 부주의 로 빌 노 에서 계 획 된 번호 정 보 를 잘못 잃 었 다 는 것 을 발견 할 수 있 습 니 다.그러면 그 가 번 호 를 수정 할 때 코드 작성 자 는 코드 에서 표 의 번호 가 메 인 표 의 번호 에 따라 변동 하 는 것 을 제어 해 야 합 니 다.그렇지 않 으 면 증빙 서 류 는 외부 키 의 제약 하에 저장 할 수 없습니다.만약 에 외부 키 의 제약 이 없 으 면그러면 데이터 의 완전 성 을 잃 게 될 것 이다.위의 세 가지 주의 점 에 따라 해결 방안 은 다음 과 같다(MsSQL)

 
--   
CREATE TABLE PP_MPSHeader( 
　　BillId INT PRIMARY KEY, 
　　BillNo VARCHAR(20) NOT NULL, 
　　PlanDate DATETIME NOT NULL 
) 
--   
CREATE TABLE PP_MPSBody( 
　　BillId INT PRIMARY KEY, 
　　LineNumber SMALLINT NOT NULL, 
　　ProductID INT NOT NULL, 
　　ProductQty DECIMAL(18,2) NOT NULL, 
PRIMARY KEY(BillId,LineNumber) 
) 
--     
ALTER TABLE PP_MPSBody 
ADD CONSTRAINT FK_PP_MPSHeader_MPSBody FOREIGN KEY(BillId) REFERENCES PP_MPSHeader(BillId) 

현재 주종 표 는 BillId 를 통 해 관련 되 고 생산 계획 이 생 겼 을 때 BillId 를 생 성 하 는 것 은 사용자 에 게 의미 가 없 으 며 그 다음 에 증빙 정보의 변경 에 있어 위의 주종 정보 조율 문제 가 발생 하지 않 을 것 이다.동시에 표 의 정 보 량 이 위의 결함 디자인 보다 적다.기 존 외 장 키 빌 노 의 길이 가 20 바이트 에서 현재 빌 아 이 드 4 바이트 로 바 뀌 면서 정보의 번 거 로 움 을 줄 였 기 때문이다.이러한 예 는 사실 매우 많다.예 를 들 어 어떤 것 은 원자재 표를 디자인 할 때 부품 번호 번 호 를 메 인 키 로 사용 하 는 것 은 구 매,생산,판매 등 관련 표 에 부품 번호 의 키 정보 가 나타 나 는 것 을 의미한다.부품 번호 정보 가 변동 이 발생 할 때 이런 모든 선 관 된 정 보 는 이에 따라 변동 해 야 한다.이런 결함 이 근본적으로 해결 되 지 않 으 면그러면 부품 번호 변동 처리 과정 을 써 서 이런 문 제 를 대량으로 처리 해 야 할 수도 있 습 니 다.처리 하 는 과정 에서 처리 하 는 순서 문 제 를 고려 해 야 할 수도 있 습 니 다.어떤 디자인 은 신분증 번 호 를 인원 표 의 메 인 키 로 사용 하지만 신분증 은 나중에 15 명 에서 18 명 으로 바 뀌 었 다.이것 은 인원 표 에서 모든 사람의 인원 신분증 정보 가 변동 해 야 한 다 는 것 을 의미한다.만약 에 특정한 사회 보장 기구 라 는 응용 프로그램의 설계 자 라면 수백 만 개의 기록 을 업데이트 해 야 한다.신분증 번호 로 연 결 된 모든 정보 기록 이 억 으로 계산 된다 면 여생 동안 다른 일 을 할 필요 가 없 을 지도 모른다.따라서 무의미 한 키 값 을 메 인 키 의 일부분 으로 선택 하 는 것 도 장기 적 인 의미 에서 이와 같은 변경 을 피 하 는 것 이다.