- 일단 char와 varchar에 대해서 말하자면,

char와 varchar의 차이는 저장 방식의 차이에서 옵니다. 예를 들어 char(10)에 'ABC'를 기록한다고 한다면, 실제 데이터는 알파벳 3문자 이므로 3바이트의 크기이지만 char(10), 즉 고정길이 문자열 10자리로 선언했기 때문에 10 바이트의 크기를 가지고 기록되게 됩니다. 좀더 크게 볼까요? 'ABC' 3바이트 길이의 문자를 char(100)에 기록하게 되면 빈 97바이트를 포함하여 100바이트를 차지하게 됩니다. 괜히 저장 공간의 낭비를 가져오죠?

하지만 varchar(100)에 'ABC' 3바이트의 문자를 기록한다면 3바이트의 길이만 사용하게 되고 97 바이트는 사용되지 않습니다. 더 예를 든다면 varchar(100)에 'A' 를 기록하면 1바이트만 사용되고, 'ABCDE'를 기록하면 5바이트를 사용하게 됩니다. 즉, 실제 데이터 길이만 사용하게 됩니다. 선언된 전체길이를 사용해서 이보다 짧은 길이의 데이터를 기록하는 경우 공간의 낭비를 가져오는 char에 비하면 varchar는 저장 공간을 효율적으로 사용한다고 할 수 있습니다.

이런 이유로 기록되는 데이터의 길이가 일정한(예를 들면 사원번호, 주민등록번호, 우편번호 등) 데이터에는 char 를 사용하고, 길이가 일정하지 않은(예를 들면 주소, 메모 등) 데이터에는 varchar 타입을 사용하게 됩니다.

하지만 항상 varchar가 char 보다 좋다고 이야기 할 수 는 없습니다. 예를 들어 varchar(100)으로 선언했는데도 이보다 작은 사이즈의 데이터 'ABC'가 들어오면 3바이트의 공간만 차지한다는 것은 "실제 길이는 100이지만 현재의 데이터 사이즈가 3이니까 3바이트 길이만 사용하자" 라는 식의 다른 정보를 기록하기위해 별도의 작업이 내부적으로 수행되어 지게 됩니다. 또한 varchar(100)에 'ABC'가 들어와서 3바이트의 공간만 할당했는데, 이 데이터가 'ABCDEFG'로 늘어나게 되면 더 늘어난 데이터를 3바이트의 공간에 저장 할 수 없기 때문에 다른 공간으로 이동하여 기록을 하고, 어느 공간으로 이동하여 기록되었는지의 위치 정보만 원래 3바이트가 기록된 자리에 가지고 있게 됩니다. 이런 식의 약간의 내부적인 오버헤드가 발생하는게 varchar의 특징입니다. 

------------------------

이름과 고객의 생년월일로 했을경우는 데이터 중복의 가능성이 남아있습니다.

보통 우리나라에서만 주민번호를 사용하기 때문에 저같은 경우도 다른나라에 회원디비를 구성할떄는

회원번호를 따로 부여하고있습니다.(물론 한국회원디비도 회원번호는 따로 부여합니다.) 

회원ID를 기본키로 잡을수도있는데 이는 회원 ID를 가진사람이 탈퇴했을경우, 보통 회원디비를 삭제시키지 않고 구분값을 가져서 탈퇴회원처리하기 떄문에 똑같은 아이디로 가입을 못하는경우가 발생됩니다.

회원번호의 예를들면 char(8)로 잡고 U0000001 로잡고 +1 증가값을 넣어서 기본키로 잡고있습니다.

핸드폰번호로 하신다고 위에서 하셧는데 핸드폰번호는 통신인증을 거치지 않는이상 허위로 기입이 가능하기 때문에 만약 임의의 번호로 회원가입을 하신분이 있다면 진짜 핸드폰 번호를 가진 주인이 가입못하는 경우도 생길 수 있습니다. 음 그리고 핸드폰 번호변경이나 가입해지에대해서 다른분이 그번호를 새로 가입했을경우도 문제가 생기겟네염..ㅡㅡ;

------------------------

음 참고로 테이블에는 한개의 기본키만이 존재할수있는데 '2개의 기본키를 하는게 좋은지' 보다 복합기본키를 사용하는게 좋은지로 바꾸면 좋을듯합니다.

신경을 많이 써주신 답변, 정말 감사합니다.
특히 입력된 VARCHAR 타입 데이터의 사이즈가 늘어났을 때 발생하는 프로세스에 대한 설명이 정말 좋았습니다.

운가라님 답변을 보고 많은 부분이 분명해졌습니다. 
일단은 예를 들어 제시해 주신 것처럼 동일한 어느정도 규칙성을 가진, 기본키가 될 만한 일련번호를 생성하는게 여러면에서 좋다는 결론을 내렸습니다.

복합 기본키에 대해서는 제가 직접 더 알아봐야겠습니다. 혹시 어떨 때 복합기본키를 쓰는경우가 발생하게 되는지 간단한 예라도 하나 들어주실 수 있나요?

음 저도 거의 복합키는 써본적이 전무하네염..

예전에 한번 써본게 다른회사 디비를 만질경우가 생겨서 쓴것인데염

회원테이블 서적테이블 대여정보테이블이 있을경우

대여정보테이블에서 대여정보에 대한 기본키값이 따로없어서

회원테이블의 아이디와 서적데이블의 서적번호를 복합키로 쓴적이 있엇네염.

복합기본키의 사용용도는 알겟는데 자세한거는 저도 잘모르겟네염..고수님들의 조언바랍니다.

핸드폰이 없는 고객은 어떻게 하실려구요? 또 핸드폰 번호 바뀌면 어떻게 하실려구요? 기본키는 고유하면서 변하지 않아야 합니다. 그리고 이름과 생년월일이 똑같은 고객이 있을 수 도 있습니다. 그런 고객들은 구분할 수 있는 방법이 없지요. 주민등록번호를 사용하면 되지 않느냐는 분들도 있는데 일단 자리수가 많아서 공간낭비도 심할 뿐더러 외국인은 회원으로 받을 수 가 없지요.

결론은...

자동 증가 필드하나 만드세요. 기본 INT형으로 하시면 문제가 없습니다.

아~ 그리고 복합키는 다대다관계를 해소할 때 테이블 하나를 생성하면서 많이 사용합니다.

질문 하신 부분에는 복합키가 적절하지 않다고 생각됩니다.

그럼, 이만~

지나가다님이 한말처럼 자동증가를 일반적으로 넣습니다.

복합키나 변경가는한것들에 대해서는 키를 넣지 말아야 합니다. 생일이나 고객이름 휴대폰등은 고유키에 맞지 않습니다.

int로 잡으시고 하셔도 4byte 이고 우리나라 인구 전부 포함해도 충분합니다. 

요새는 주민번호 넣는 것이 불법입니다. 물론 비번도 암호화해야되서 어느정도는 크게 잡아주셔야 합니다.