데이터베이스와 그 작동 방식에 대한 이론에 익숙하지 않습니다. 정수보다 기본 키에 문자열을 사용하는 것이 성능 관점 (삽입 / 업데이트 / 쿼리)에서 속도가 느립니까?
답변
기술적으로는 가능하지만 문자열이 기본 키로 이해되는 경우 아마도 사용해야합니다. 이것은 모두 테이블의 크기와 기본 키가 될 문자열의 길이에 달려 있습니다 (더 긴 문자열 == 비교하기 더 어렵습니다). 필자는 수백만 행이있는 테이블에 반드시 문자열을 사용하지는 않지만 작은 테이블에서 문자열을 사용하면 성능 저하의 양이 정수를 사용하여 두통을 겪을 수 있습니다 데이터와 관련하여 아무 의미도 없습니다.
답변
문자열을 기본 키로 사용하는 또 다른 문제는 인덱스가 지속적으로 순차적으로 배치되기 때문에 새 키를 만들 때 순서 중간에있는 인덱스를 다시 정렬해야하는 경우입니다. 정수, 새 키가 색인 끝에 추가됩니다.
답변
시퀀스 중간에 삽입이 발생하는 클러스터형 인덱스가있는 테이블에 삽입하면 인덱스를 다시 쓰지 않습니다. 데이터를 구성하는 페이지를 다시 쓰지 않습니다. 행이 이동할 페이지에 공간이 있으면 해당 페이지에 배치됩니다. 단일 페이지가 재구성되어 페이지의 올바른 위치에 행이 배치됩니다. 페이지가 가득 차면 페이지의 행 절반이 한 페이지로 이동하고 절반이 다른 페이지로 이동하여 페이지 분할이 발생합니다. 그런 다음 페이지는 클러스터형 인덱스가있는 테이블 데이터를 구성하는 연결된 페이지 목록으로 다시 연결됩니다. 기껏해야 2 페이지의 데이터베이스를 작성하게됩니다.
답변
문자열은 조인 속도가 느리고 실제 생활에서는 매우 독특하지 않습니다 (심지어 있어야 할 때조차도). 유일한 장점은 이름을 얻기 위해 기본 테이블에 조인하는 경우 조인 수를 줄일 수 있다는 것입니다. 그러나 문자열도 종종 변경 될 수 있으므로 회사 이름이 변경되거나 결혼 할 때 모든 관련 레코드를 수정해야하는 문제가 발생합니다. 이것은 큰 성능 저하가 될 수 있으며 어떻게 든 관련되어야하는 모든 테이블이 관련이없는 경우 (이것이 생각보다 자주 발생하는 경우) 데이터가 일치하지 않을 수 있습니다. 레코드 수명 동안 변경되지 않는 정수는 성능 관점뿐만 아니라 데이터 무결성 관점에서 훨씬 안전한 선택입니다. 자연 키는 일반적으로 데이터 유지 관리에 적합하지 않습니다.
또한 두 세계의 최고 점은 종종 자동 증가 키 (또는 일부 특수한 경우 GUID)를 PK로 사용하고 자연 키에 고유 인덱스를 넣는 것입니다. 더 빠른 조인을 얻거나 중복 레코드를 얻지 않으며 회사 이름이 변경되어 백만 개의 하위 레코드를 업데이트 할 필요가 없습니다.
답변
고유 한 경우 기본 키로 사용하는 것은 중요하지 않습니다. 속도 나 우수한 데이터베이스 설계에 관심이있는 경우 데이터 복제를 계획하지 않는 한 int를 사용하고 GUID를 사용하십시오.
이것이 액세스 데이터베이스이거나 작은 응용 프로그램이라면 누가 정말로 관심을 갖습니다. 나는 우리 대부분의 개발자들이 오래된 int 또는 guid를 앞쪽으로 때리는 이유는 프로젝트가 우리를 성장시키는 방법을 가지고 있기 때문에 자신에게 성장 옵션을 남기고 싶어하기 때문이라고 생각합니다.
답변
변수가 너무 많습니다. 그것은 테이블의 크기, 인덱스, 문자열 키 도메인의 특성에 달려 있습니다 …
일반적으로 정수가 빠릅니다. 그러나 차이가 충분히 커질 것입니까? 말하기 어렵다.
또한 문자열을 선택하려는 동기는 무엇입니까? 숫자 자동 증가 키도 종종 훨씬 쉽습니다 . 의미론인가? 편의? 복제 / 연결 끊김 문제? 귀하의 답변이 옵션을 제한 할 수 있습니다. 이것은 또한 당신이 잊고있는 세 번째 “하이브리드”옵션을 떠올리게합니다 : Guids.
답변
데이터가 설명하고 데이터의 의도 된 용도에 잘 맞는 주제와 일치하는 단순하고 건전한 디자인을 얻을 때까지 성능에 대해 걱정하지 마십시오. 그런 다음 성능 문제가 발생하면 시스템을 조정하여 문제를 해결할 수 있습니다.
이 경우 문자열을 자연스러운 기본 키로 사용하고 신뢰할 수 있다면 거의 항상 더 좋습니다. 문자열이 합리적으로 짧으면 최대 25 자 정도라고 문자열을 걱정하지 마십시오. 성능면에서 큰 가격을 지불하지 않습니다.
데이터 입력 사용자 또는 자동 데이터 소스가 항상 가정 된 자연 키에 대한 값을 제공합니까, 아니면 생략합니까? 입력 데이터에서 때때로 잘못 되었습니까? 그렇다면 오류는 어떻게 감지되고 수정됩니까?
쿼리를 지정하는 프로그래머와 대화식 사용자는 자연 키를 사용하여 원하는 것을 얻을 수 있습니까?
자연 키를 신뢰할 수 없으면 대리를 발명하십시오. 대리를 발명하면 정수도 발명 할 수 있습니다. 그런 다음 사용자 커뮤니티에서 대리를 숨길 것인지에 대해 걱정해야합니다. 대리 키를 숨기지 않은 일부 개발자는 후회했습니다.
