수십억 개의 행이 있고 사용자 이름 (varchar)이있는 사용자 테이블이 있는데 고유 인덱스 대신 기본 키로 사용해야합니까? 여분의 필드 user_id (int)를 추가하고 그 대신에 기본 키를 만드는 장점이나 단점은 무엇입니까? 내가 어디에 join_ 조건에 대한 조인 int에서 조인이 varchar에 조인보다 빠를 것이라고 말하기를 제외하고 user_id를 어디에서 사용할지 모르겠다. 아니면 그게 맞습니까? (두 필드가 모두 인덱싱되기 때문에)데이터베이스 기본 키
업데이트 : 사용자 이름 변경은 옵션이 아닌 것으로 가정합니다.
우선, Frederik의 두 번째 의견 : 어떤 비즈니스 또는 기능적 가치도 테이블의 기본 키로 간주하지 않는다는 것을 확고히 믿습니다. 현재 사용자 이름을 변경할 수있는 옵션이 없을 수도 있지만 나중에있을 수 있습니다. 그렇지 않더라도 습관에 빠져서 패러다임을 혼합하는 대신 모든 테이블과 일관성을 유지하는 것이 좋습니다.
숫자 (또는 어떤 방식 으로든 순차적 인) 기본 키를 사용하는 두 번째 이유는 삽입 및 업데이트 속도입니다. 이를 변경할 수 있지만 기본적으로 테이블의 기본 키는 클러스터 된 인덱스이기도합니다. 클러스터 된 인덱스는 테이블의 행의 실제 순서를 결정하므로 값을 순서없이 삽입하면 데이터베이스 엔진이 모든 행을 아래로 이동하여 올바른 위치에 삽입 할 수 있습니다. 수백만 행의 테이블을 사용하면 그다지 중요하지 않은 삽입 또는 업데이트 작업이 될 수 있습니다.
비즈니스 관련 기본 키를 사용하는 이유를 발견했습니다. 일괄 업데이트 및 가져 오기를 활성화하려면. 예 : 행성의 데이터베이스. 외출하는 비동기 클라우드 기반 앱이 있는데 데이터를 가져 와서 임시 데이터베이스에 행을 만듭니다. 그런 다음 가져 오기를 통해 프로덕션 데이터베이스와 병합됩니다. 새로운 행성 메타 데이터 테이블 레코드는 행성 이름에 키를 입력하면 쉽게 가져올 수 있습니다. 그러나 planet_id에 키가 입력되어 있으면 작동하지 않으며 데이터베이스간에 동일하지 않습니다. 더구나 행성의 이름과 같은 것이 거의 변하지 않을 것입니다. 생각? – Dogweather
@Dogweather : 가치있는 것을 위해 대리 키에 대한 내 견해가 변경되었습니다. 데이터가 고유하고 필수적이며 안정적인 데이터를 정의하는 경우 확실히 유효한 키입니다. –
내가 숫자 PK를 선호하는 이유는 사용자 이름을 쉽게 변경할 수 있도록 허용하기 위해서입니다.
사용자 이름이 기본 키인 경우 해당 사용자와 관련된 모든 레코드도 사용자 이름을 변경할 때 변경해야한다는 것을 의미합니다.
데이터베이스가 여러 가지 방법을 통해 숫자 PK에 대한 적절한 ID를 생성 할 수 있다는 점에 유의하십시오. MySQL에서는 필드에 "auto_increment"속성을 추가하고, Postgres와 Oracle에서는 시퀀스를 통해 속성을 추가합니다.
수백 억 개의 행이 있다면 사용자 이름을 사용하는 것이 더 낫다는 것이 맞습니다. 테이블 사이에 변형 된 PK가 떠 다니는 것을 피하려고합니다. 절대적으로 필요한 경우가 아니면 코드를 따라가는 사람들이 모든 것을 유지 관리하기가 더 어려워집니다.
사용자 이름을 변경하는 것이 옵션이 아니라면 추가 숫자 pk를 사용할 이유가 없습니까? – user157195
@ user157195 : 염두에두고 답변을 업데이트했습니다. 여기서 어렵지 않고 빠른 규칙은 없으며 숫자 PK를 사용하는 데 제약을받지 않습니다. 나중에 변경하려는 경우 얼마나 많은 작업을해야하는지에 대한 문제 일뿐입니다. –
기본 키로 추가 필드를 추가하는 것이 좋습니다.
주된 이유는 - 기본 키는 '비즈니스'가치가 없어야한다는 것입니다. 기본 키는 단지 관리 항목 일 뿐이며, 이는 데이터베이스에서만 중요하므로 무결성을 보장 할 수 있습니다.
Brian이 이미 언급 한 것처럼 서로 게이트 기본 키를 추가하여 사용자가 문제없이 사용자 이름을 변경할 수 있도록 할 수 있습니다.
기본 키의 값은 절대로 변경하면 안됩니다. 그렇지 않으면 많은 외래 키가있을 때 업데이트가 매우 비쌀 수 있습니다. 모든 변경 사항은 관련 테이블에 계단식으로 연결되어야합니다.
다음으로 정수는 예를 들어 4 바이트이며 사용자 이름 열은 훨씬 큽니다.
이것은 관련 테이블에서 훨씬 많은 공간을 차지할뿐만 아니라 인덱스가 커질 수도 있음을 의미합니다.
색인을 구성하는 버킷에는 '레코드 포인터'가 적게 포함됩니다. 즉, 버킷이 많아 지므로 색인이 더 느려집니다.
+1 "비즈니스"가치에 대한 의견 및 색인 크기에 대한 통찰력 – Rob
예, Frederik의 의견뿐만 아니라 비즈니스 가치 의견에 +1을 추가했습니다. 대부분의 숫자 int 열은 현재 8 바이트로 기본 설정되어 있지만, 사용자 이름이 8 자로 제한되어 있어도 lexographic clustering이 없기 때문에보다 균일하고 효율적인 b-tree 인덱스를 만들 수 있다고 생각합니다. –
기존 키에 다른 열을 추가했습니다. 기존 기본 키에 추가 필드를 추가하는 것을 연결된 기본 키라고도합니다.
http://www.relationaldbdesign.com/relational-database-analysis/module2/concatenated-primary-keys.php
혹시 사용자가 자신의 사용자 이름을 변경할 수 하시겠습니까? VARCHAR의 기간은 얼마입니까? 후자가 더 긴 키 길이를 갖는 경우, INTEGER에 근거한 | 조는 VARCHAR에서의 | 조보다 더 빠를 수 있습니다. – Rob
아니요 사용자 이름을 변경하지 않기를 바랍니다. – user157195
절대 필요하지 않으실 것입니다. 나는 미래를 예측할 수 있었으면 좋겠다 ... – Rob