자동 증가 기본 키를 사용하는 경우와 사용하지 않는 경우
자동 증가 정수를 테이블에 기본 키로 추가할지 여부를 결정하기위한 "모범 사례"를 알아 내려고합니다.
화학 원소에 대한 데이터가 포함 된 테이블이 있다고 가정 해 보겠습니다. 각 요소의 원자 번호는 고유하며 절대 변경되지 않습니다. 따라서 각 열에 대해 자동 증가 정수를 사용하는 것보다 원자 번호를 사용하는 것이 더 합리적 일 것입니다. 맞습니까?
책 테이블이 있어도 마찬가지일까요? 기본 키에 ISBN 또는 자동 증가 정수를 사용해야합니까? 아니면 각 개인의 SSN이 포함 된 직원 표?
질문에 도움이 될 수있는 Stack Overflow에 이미 해결 된 많은 질문이 있습니다. 참조 여기 , 여기 , 여기 와 여기 .
찾아야 할 용어 : 대리 키 .
도움이 되었기를 바랍니다.
이것은 양측에 많은 감정을 가진 매우 논쟁의 여지가있는 질문입니다.
내 겸손한 의견으로는 ISBN과 같이 유용하고 사용 가능한 자연 키가 있으면 그것을 사용합니다. 어쨌든 데이터베이스에 저장하겠습니다. 예, 자연 키는 일반적으로 정수 자동 증가 키보다 크지 만이 문제는 과장된 것 같습니다. 오늘날 디스크 공간은 저렴합니다. 처리하는 데 더 오래 걸리는 것에 대해 더 걱정합니다. 80 바이트 텍스트 필드를 기본 키로 사용한다면 아니오라고 대답 할 것입니다. 그러나 8 바이트 큰 정수 대신 10 바이트 ISBN을 사용하려는 경우 성능이 크게 저하되는 것을 상상할 수 없습니다.
때로는 자연 키에 성능상의 이점이 있습니다. 예를 들어, 주어진 책이 얼마나 많이 팔렸는지 알고 싶다고 가정 해 보겠습니다. Book 마스터 레코드의 데이터는 신경 쓰지 않습니다. 기본 키가 ISBN이면 "select count (*) from sale where isbn = '143573338X'"라고 간단히 작성할 수 있습니다. 자동 증가 키를 사용했다면 isbn을 조회하기 위해 조인을해야 할 것이고 쿼리는 "(bookid) where isbn = '143573338X'를 사용하여 book join sale에서 select count (*) from book join sale '과 같이 더 복잡하고 느려집니다.) ". (그리고 저는이 특정 ISBN이 제 책에 대한 것이므로 판매 레코드 수가 매우 적으므로 조인하고 추가 레코드 하나를 읽는 것이 백분율 차이가 큽니다!)
자연 키의 또 다른 장점은 데이터베이스에서 작업해야 할 때 키별로이 테이블을 다시 참조하는 레코드를 볼 때 참조하는 레코드를 쉽게 볼 수 있다는 것입니다.
반면에, 좋고 명백한 자연적인 열쇠가 없다면, 미친 열쇠를 함께 뭉치려고하지 마십시오. 나는 사람들이 고객의 이름, 생년월일, 우편 번호의 처음 6자를 연결하여 자연스러운 키를 만들고 그것이 독특 해 지도록기도하는 것을 보았습니다. 그런 어리 석음은 그저 자신을 괴롭히는 것입니다. 종종 사람들은 시퀀스 번호를 사용하여 어쨌든 고유한지 확인합니다. 그 시점에서 왜 귀찮게합니까? 시퀀스 번호 만 키로 사용하지 않는 이유는 무엇입니까?
바로 거기에 아이디어가 있습니다.
모델링중인 항목에 대한 고유 키가 이미 존재하지 않는 경우 자동 증가를 고유 키로 사용해야합니다. 따라서 Elements의 경우 원자 번호 또는 책 ISBN 번호를 사용할 수 있습니다.
그러나 사람들이 메시지 게시판에 메시지를 게시하는 경우 고유 ID가 필요하지만 자연스럽게 ID가 포함되지 않으므로 목록에서 다음 번호를 할당합니다.
가능한 경우 자연 키를 사용하는 것이 합리적입니다. 필드를 기본 키로 만들고 성능을 위해 인덱싱되었는지 확인하십시오.
정수 자동 증분 방식에서 본 주요 문제는 데이터를 내 보내서 다른 db 인스턴스로 가져 오거나 아카이브 및 복원 작업을 할 때입니다. 정수는 참조하는 데이터와 관련이 없기 때문에 기존 데이터베이스에 데이터를 복원하거나 추가 할 때 중복이 있는지 확인할 방법이 없습니다. 행에 포함 된 데이터와 PK 간의 관계를 원하지 않으면 guid를 사용합니다. 보기에는 그다지 사용자 친화적이지 않지만 위의 문제를 해결합니다.
ISBN 및 SSN 사용과 관련하여 다른 테이블의 행이 얼마나 많은 행이 외래 키를 통해 참조 할 것인지 생각해야합니다. 이러한 ID는 정수보다 훨씬 더 많은 공간을 차지하므로 디스크 공간을 낭비하고 조인 성능이 저하 될 수 있습니다.
자동 증가 정수를 테이블에 기본 키로 추가할지 여부를 결정하기위한 "모범 사례"를 알아 내려고합니다.
PKey가 사용자 관리 데이터의 일부가 아닌 데이터 세트에서 고유 식별자로 사용합니다.
화학 원소에 대한 데이터가 포함 된 테이블이 있다고 가정 해 보겠습니다. 각 요소의 원자 번호는 고유하며 절대 변경되지 않습니다. 따라서 각 열에 대해 자동 증가 정수를 사용하는 것보다 원자 번호를 사용하는 것이 더 합리적 일 것입니다. 맞습니까?
예.
책 테이블이 있어도 마찬가지일까요? 기본 키에 ISBN 또는 자동 증가 정수를 사용해야합니까? 아니면 각 개인의 SSN이 포함 된 직원 표?
ISBN / SS #은 타사에서 할당하며 스토리지 크기가 크기 때문에 행을 고유하게 식별하는 데 매우 비효율적 인 방법입니다. PKey는 테이블을 조인 할 때 유용합니다. 정수와 같은 작고 간결한 형식을 사용할 수있을 때 고유 식별자로 수많은 텍스트 문자 인 ISBN과 같은 대용량 데이터 형식을 사용하는 이유는 무엇입니까?
내가 알고있는 오래된 주제이지만 고려해야 할 또 다른 사항은 대부분의 RDBMS가 PK를 사용하여 디스크에 블록을 배치한다는 점을 감안할 때 자동 증가 PK를 사용하면 경합이 크게 증가한다는 것입니다. 이것은 당신의 아기 데이터베이스에 대한 문제가 아닐 수도 있지만, 마을의 더 큰 끝에서 엄청난 성능 문제를 일으킬 수 있다고 믿습니다.
당신이 경우에 있어야 자동 증가 ID를 사용하는, 어쩌면로 사용을 고려 부분 PK가의. 독특함을 유지하기 위해 끝 부분에 고정하십시오 .....
또한 대리자로 점프하기 전에 자연 PK에 대한 모든 가능성을 소진하는 것이 가장 좋습니다. 사람들은 일반적으로 이것에 게으르다.
'programing' 카테고리의 다른 글
| C #으로 웹캠 비디오를 스트리밍하려면 어떻게해야합니까? (0) | 2021.01.16 |
|---|---|
| Swift 2, 경고 : dyld 공유 캐시에서 Objective-C 클래스 정보를로드 할 수 없습니다. (0) | 2021.01.16 |
| 글꼴 색상 속성의 이상한 것이 실제 색상을 생성하는 이유는 무엇입니까? (0) | 2021.01.16 |
| 속성 대신 마커 인터페이스를 사용하는 설득력있는 이유 (0) | 2021.01.16 |
| PHP : 세션의 기본 수명은 얼마입니까? (0) | 2021.01.15 |