2

여기에 최적의 솔루션이 무엇인지 궁금합니다.SQL Server 정규화 전술 : varchar vs int ID

정규화 된 데이터베이스가 있다고 가정 해 봅니다. 전체 시스템의 기본 키는 varchar입니다. 내가 궁금해하는 건 정상화를 위해이 varchar를 int에 연결해야합니까 아니면 그대로 두어야합니까? 그것은 VARCHAR로 떠나 간단하지만

예를 들어 내가

People 
====================== 
name  varchar(10) 
DoB  DateTime  
Height int 

Phone_Number 
====================== 
name  varchar(10) 
number varchar(15) 

을 가질 수 또는 내가

People 
====================== 
id  int Identity 
name  varchar(10) 
DoB  DateTime 
Height int 

Phone_Number 
====================== 
id  int 
number varchar(15) 

다른 여러 일대 다 관계를 추가 할 수 그것은 더 최적의 수 있습니다 당연하지.

모두 어떻게 생각하십니까? 어느 쪽이 더 낫고 왜?

답변

7

실제 이름을 기본 키로 사용할 수 있습니까? 같은 이름을 가진 몇몇 사람들의 고위험이 있지 않습니까?

정말 운이 좋으면 이름 속성을 기본 키로 사용할 수 있습니다. 그러면 모든 것을 사용하십시오. 하지만 종종 customer_id와 같이 뭔가를 만들어야합니다.

마지막으로 : "NAME"은 적어도 하나의 DBMS에서 예약어이므로 다른 이름을 사용하는 것이 좋습니다. fullname.

+0

확실히. 그것은 그것의 이론에 대한 단순한 예입니다. – theo

+0

@Troels Arvin : +1, 단일 정수형이 아닌 VARCHAR을 사용하여 모든 곳에서 데이터를 복제한다는 사실을 포함하십시오. – user7116

3

VARCHAR이 더 큰 경우 데이터베이스 전반에 걸쳐 상당량의 데이터가 중복되고 있음을 알았을 것입니다. 숫자 ID 열을 사용하는 경우 외래 키 열을 다른 테이블에 추가 할 때 거의 동일한 양의 데이터를 복제하지 않습니다.

또한, 텍스트 데이터가 비교의 관점에서 왕실의 고통이, 당신의 인생은 당신이 을 수행 할 때 훨씬 더 쉽게 WHERE ID = user_id를대 WHERE은 inputName (또는 뭔가 유사한) LIKE 이름입니다.

+0

최적화 : 조기 최적화를 수행하지 마십시오. 그리고 같은 일 (int와 varchar)에 대해 여러 개의 식별자가 있다면 더 자주 가입하게 될 수도 있습니다. 비교 : 실제 세계 (고객/판매 이름 등)와 상호 작용하기 때문에 종종 이름을 처리해야합니다. –

+0

코드 최적화는 데이터베이스 최적화와 동일하지 않습니다. 관계에 ID 필드를 사용하는 것이 최상의 방법이며 일을 수행하는 최적의 방법입니다. 데이터베이스 디자인에 코드 패러다임을 할당하지 마십시오. 특히이 경우 이름이 적절한 기본 키가 아니기 때문에. – blowdart

+1

ID 필드를 사용하는 것이 "모범 사례"가 아닙니다. 가장 좋은 방법은 상황에 따라 다르다는 것입니다. 그건 그렇고 : 이것은 데이터베이스 필드에서 가장 오래된 토론 중 하나 인 논의가 끝나지 않을 것입니다. –

6

PK와 같이 모든 종류의 비 합성 데이터 (예 : 사용자가 애플리케이션에서 생성 한 데이터)를 사용하는 것은 문제가 있습니다. 문화/지역화의 차이, 대소 문자 구분 (DB 데이터 정렬에 따른 다른 문제)에 대해 걱정할 필요가 있습니다. 사용자가 입력 한 데이터가 변경되는 경우 데이터 문제가 발생할 수 있습니다.

사용자가 생성하지 않은 데이터 (순차 GUID (DB가 지원하지 않거나 페이지 분할을 신경 쓰지 않는다면 비 순차적) 또는 ID int (GUID가 필요하지 않은 경우))는 훨씬 쉽고 안전합니다.

중복 데이터 : 비 합성 키를 사용하면 어떻게 보호되는지 보지 못합니다. 사용자가 여전히 "Bob K. Smith"또는 "Smith, Bob"또는 "bob smith"대신 "Bob Smith"를 입력하는 문제가 있습니다. 복제 관리는 키가 합성인지 여부에 관계없이 (거의 동일합니다) 필요합니다. 또는 비 합성 키 및 비 합성 키는 합성 키가 깔끔하게 피할 수있는 여러 가지 잠재적 인 문제를 가지고 있습니다.

많은 프로젝트에서 이에 대해 걱정할 필요가 없습니다 (예 : 엄격한 제한된 조합 선택은 많은 제약을 피할 수 있지만 일반적으로 합성 키를 선호합니다). 이것은 유기적 인 열쇠로 성공할 수 없다는 것을 말하는 것은 아니지만 많은 프로젝트에서 더 나은 선택이 아닙니다.

+1

자동 생성 된 값을 기반으로하는 PK를 사용하면 복제 된 정보가 데이터베이스로 들어가기 쉽고 실제 세계에서 확인할 수없는 데이터베이스에 데이터가 있기 때문에 데이터 품질이 떨어질 수 있습니다. –

+0

@Troels 다행히도 우리 모두는 우리 자신의 의견을 말할 권리가 있지만 나는 귀하의 진술에 완전히 동의하지 않습니다. –

+0

@technophile : +1 스포트. – user7116

10

중요한 실제 데이터베이스 응용 프로그램을 개발 한 대다수의 사람들은 대리 키가 유일하게 현실적인 솔루션이라고 말합니다.
나는 학문적 공동체가 동의하지 않을 것이지만 그것은 이론적 순도와 실용성 사이의 차이점이라는 것을 알고 있습니다.

일부 테이블에 복합 기본 키가있는 곳에서 비 대리 키를 사용하는 테이블간에 조인을해야하는 합리적인 크기의 쿼리는 유지 관리가 쉽지 않습니다.

+0

@Darrel Miller : +1, 대용 키없이 볼 수있는 유일한 DB는 Access에서 온 MS Access 또는 일부 SQL Server DB에있는 것입니다. – user7116

+0

나는 학자가 대리 키에 정말로 반대한다고 생각하지 않습니다. – BobbyShaftoe

1

"이름"필드가 기본 키로 실제로 적합한 경우 다음을 수행하십시오. 이 경우 데이터베이스는 이 아니며은 더 크게 정규화됩니다. FK 제약 조건은 대리 키와 마찬가지로 문자열의 무결성을 보장하기 때문에 외래 키에 대해 중복 된 문자열을 얻을 수는 있지만 정규화 문제는 아닙니다.

그러나 "이름"이 무엇인지 설명하지는 않습니다. 실제로는 문자열이 기본 키로 적절하지는 않습니다. 사람의 이름이라면 둘 이상의 사람이 같은 이름을 가질 수 있기 때문에 PK로 작동하지 않을 것이며 사람들은 이름을 바꿀 수 있습니다.

1

다른 사람이 언급하지 않은 것 중 하나는 int 필드의 조인이 varchar 필드의 조인보다 성능이 좋은 경향이 있다는 것입니다.

그리고 나는 사람들 (기업)의 이름을 사용할 때 항상 대리 키를 사용합니다. 왜냐하면 그것들은 시간이 지남에 따라 고유하지 않기 때문입니다. 예를 들어, 우리 데이터베이스에는 100 개 이상의 동일한 이름의 인스턴스가있는 164 개의 이름이 있습니다. 이는 핵심 필드로 이름을 사용하는 것을 고려하는 위험을 분명히 보여줍니다.

+0

조인은 조인하지 않을 때 가장 잘 수행됩니다. 예를 들어, 유기농 키를 사용하면 전화 번호를 이름으로 찾기 위해 가입 할 필요가 없습니다. – Constantin

+1

전화 번호는 이름과 일대 다 관계이므로 일반적으로 다른 테이블에 입력하면됩니다. – HLGEM

1

원래 질문은 정규화 중 하나가 아닙니다. 정규화 된 데이터베이스가있는 경우 명시된 바와 같이 정규화 이유로 데이터베이스를 변경할 필요가 없습니다.

정말로 두 가지 문제가 있습니다. 첫 번째는 int 또는 varchar가 기본 키 및 외래 키로 사용하기에 적합한 지 여부입니다. 두 번째는 문제 정의에 제공된 자연 키를 사용할 수 있는지 또는 자연 키 대신 대체 키 (대리 키)를 생성해야하는지 여부입니다.

정수는 varchars보다 약간 간결하며 인덱스 처리와 같은 경우에는 좀 더 효율적입니다. 그러나 그 차이는 압도적이지 않습니다. 아마이 근거만으로는 결정을 내려서는 안됩니다.

제공되는 자연 키가 실제로 자연 키로 작동하는지 여부는 더 중요합니다. "이름"열의 중복 문제 만이 유일한 문제는 아닙니다. 어떤 사람이 자신의 이름을 바꿀 때 어떤 일이 일어나게되는지에 대한 문제도 있습니다. 이 문제는 여러분이 제시 한 예제에서 나타나지는 않았지만 다른 많은 데이터베이스 응용 프로그램에서 나타납니다. 예를 들어 학생이 수강 한 모든 과목 중 4 년 동안의 성적표가 있습니다. 여자는 결혼하여 4 년 동안 그녀의 이름을 바꿀 수 있습니다. 그리고 이제 당신은 붙어 있습니다.

이름을 변경하지 않고 그대로두면 더 이상 실제 세계와 일치하지 않거나 그 사람이 선택한 모든 과정에서 소급 적으로 업데이트되므로 데이터베이스가 당시 만든 인쇄 명부와 일치하지 않게됩니다 .

구체화 키를 결정할 경우 이제 응용 프로그램이 가상 커뮤니티 키의 값을 사용자 커뮤니티에 표시할지 여부를 결정해야합니다. 이것은 벌레의 또 다른 전체 깡통이며,이 토론의 범위를 벗어납니다.