답변:
기술적으로는 가능하지만 문자열이 기본 키로 이해되는 경우 아마도 사용해야합니다. 이것은 모두 테이블의 크기와 기본 키가 될 문자열의 길이에 달려 있습니다 (더 긴 문자열 == 비교하기 더 어렵습니다). 필자는 수백만 행이있는 테이블에 반드시 문자열을 사용하지는 않지만 작은 테이블에서 문자열을 사용하면 성능 저하의 양이 정수를 사용하여 두통을 겪을 수 있습니다 데이터와 관련하여 아무 의미도 없습니다.
문자열을 기본 키로 사용하는 또 다른 문제는 인덱스가 지속적으로 순차적으로 배치되기 때문에 새 키를 만들 때 순서 중간에있는 인덱스를 다시 정렬해야하는 경우입니다. 정수, 새 키가 색인 끝에 추가됩니다.
시퀀스 중간에 삽입이 발생하는 클러스터형 인덱스가있는 테이블에 삽입하면 인덱스를 다시 쓰지 않습니다. 데이터를 구성하는 페이지를 다시 쓰지 않습니다. 행이 이동할 페이지에 공간이 있으면 해당 페이지에 배치됩니다. 단일 페이지가 재구성되어 페이지의 올바른 위치에 행이 배치됩니다. 페이지가 가득 차면 페이지의 행 절반이 한 페이지로 이동하고 절반이 다른 페이지로 이동하여 페이지 분할이 발생합니다. 그런 다음 페이지는 클러스터형 인덱스가있는 테이블 데이터를 구성하는 연결된 페이지 목록으로 다시 연결됩니다. 기껏해야 2 페이지의 데이터베이스를 작성하게됩니다.
문자열은 조인 속도가 느리고 실제 생활에서는 매우 독특하지 않습니다 (심지어 있어야 할 때조차도). 유일한 장점은 이름을 얻기 위해 기본 테이블에 조인하는 경우 조인 수를 줄일 수 있다는 것입니다. 그러나 문자열도 종종 변경 될 수 있으므로 회사 이름이 변경되거나 결혼 할 때 모든 관련 레코드를 수정해야하는 문제가 발생합니다. 이것은 큰 성능 저하가 될 수 있으며 어떻게 든 관련되어야하는 모든 테이블이 관련이없는 경우 (이것이 생각보다 자주 발생하는 경우) 데이터가 일치하지 않을 수 있습니다. 레코드 수명 동안 변경되지 않는 정수는 성능 관점뿐만 아니라 데이터 무결성 관점에서 훨씬 안전한 선택입니다. 자연 키는 일반적으로 데이터 유지 관리에 적합하지 않습니다.
또한 두 세계의 최고 점은 종종 자동 증가 키 (또는 일부 특수한 경우 GUID)를 PK로 사용하고 자연 키에 고유 인덱스를 넣는 것입니다. 더 빠른 조인을 얻거나 중복 레코드를 얻지 않으며 회사 이름이 변경되어 백만 개의 하위 레코드를 업데이트 할 필요가 없습니다.
변수가 너무 많습니다. 그것은 테이블의 크기, 인덱스, 문자열 키 도메인의 특성에 달려 있습니다 ...
일반적으로 정수가 빠릅니다. 그러나 차이가 충분히 커질 것입니까? 말하기 어렵다.
또한 문자열을 선택하려는 동기는 무엇입니까? 숫자 자동 증가 키도 종종 훨씬 쉽습니다 . 의미론인가? 편의? 복제 / 연결 끊김 문제? 귀하의 답변이 옵션을 제한 할 수 있습니다. 이것은 또한 당신이 잊고있는 세 번째 "하이브리드"옵션을 떠올리게합니다 : Guids.
데이터가 설명하고 데이터의 의도 된 용도에 잘 맞는 주제와 일치하는 단순하고 건전한 디자인을 얻을 때까지 성능에 대해 걱정하지 마십시오. 그런 다음 성능 문제가 발생하면 시스템을 조정하여 문제를 해결할 수 있습니다.
이 경우 문자열을 자연스러운 기본 키로 사용하고 신뢰할 수 있다면 거의 항상 더 좋습니다. 문자열이 합리적으로 짧으면 최대 25 자 정도라고 문자열을 걱정하지 마십시오. 성능면에서 큰 가격을 지불하지 않습니다.
데이터 입력 사용자 또는 자동 데이터 소스가 항상 가정 된 자연 키에 대한 값을 제공합니까, 아니면 생략합니까? 입력 데이터에서 때때로 잘못 되었습니까? 그렇다면 오류는 어떻게 감지되고 수정됩니까?
쿼리를 지정하는 프로그래머와 대화식 사용자는 자연 키를 사용하여 원하는 것을 얻을 수 있습니까?
자연 키를 신뢰할 수 없으면 대리를 발명하십시오. 대리를 발명하면 정수도 발명 할 수 있습니다. 그런 다음 사용자 커뮤니티에서 대리를 숨길 것인지에 대해 걱정해야합니다. 대리 키를 숨기지 않은 일부 개발자는 후회했습니다.
문자열을 기본 키로 사용하는 이유는 무엇입니까?
기본 키를 자동 증분 정수 필드로 설정하고 문자열 필드에 색인을 넣습니다.
이렇게하면 테이블에서 검색을 수행하면 비교적 빠르며 모든 조인 및 일반 조회는 속도에 영향을 미치지 않습니다.
인덱싱되는 문자열 필드의 양을 제어 할 수도 있습니다. 다시 말해, 충분하다고 생각되면 "처음 5 자만 색인화"라고 말할 수 있습니다. 또는 데이터가 비교적 유사 할 수있는 경우 전체 필드를 색인화 할 수 있습니다.
성능 관점에서-예 문자열 (PK)은 정수 (PK)를 사용하여 달성 한 성능과 비교할 때 성능을 느리게합니다. 여기서 PK ---> 기본 키.
요구 사항 관점에서-이것은 여전히 귀하의 질문의 일부는 아니지만 언급하고 싶습니다. 여러 테이블에서 거대한 데이터를 처리 할 때 일반적으로 특정 테이블에 설정할 수있는 가능한 키 집합을 찾습니다. 이것은 주로 많은 테이블이 있고 주로 각 또는 일부 테이블이 어떤 관계 (외래 키 개념)를 통해 다른 테이블과 관련되기 때문입니다. 따라서 항상 정수를 기본 키로 선택할 수는 없지만 3, 4 또는 5 속성을 해당 테이블의 기본 키로 조합해야합니다. 레코드를 다른 테이블과 관련시킬 때 해당 키를 외래 키로 사용할 수 있습니다. 이것은 필요할 때 다른 테이블에 레코드를 관련시키는 데 유용합니다.
따라서 최적의 사용을 위해-항상 1 또는 2 개의 문자열 속성으로 1 또는 2 개의 정수를 조합하지만 필요한 경우에만 다시 조합합니다.
기본적으로 ASPNetUserIds는 128 자 문자열이며 성능은 괜찮습니다.
키가있는 경우 HAS 테이블에서 고유하기는 키해야합니다. 이유는 다음과 같습니다.
기본 문자열 키 = 올바른 DB 관계, 1 문자열 키 (기본) 및 1 문자열 인덱스 (기본).
다른 옵션은 일반적인 INT 키이지만, 문자열이 경우 HAS 고유해야합니다 당신은 아마 아직도 유효한지 확인할 수 있기 때문에 논스톱 쿼리의 인덱스를 추가하거나 독특한 있는지 확인해야합니다.
따라서 int identity key = 잘못된 DB 관계, 1 int key (Primary), 1 int index (Primary), 아마도 고유 문자열 Index를 사용하고 동일한 문자열을 수동으로 유효성 검사 해야하는 것은 존재하지 않습니다 (sql 확인과 같은 것) ).
기본 키에 대한 문자열을 통해 int를 사용하여 더 나은 성능을 얻으려면, 문자열이 때 HAS 고유해야합니다, 그것은 매우 이상한 상황이 될 것이다. 나는 항상 문자열 키를 사용하는 것을 선호했습니다. 당신이 때까지 그리고 엄지 손가락의 좋은 규칙으로, 데이터베이스를 비정규하지 않는 필요해 에.