데이터베이스 (5) 설계 1 - Key 설계

 

 

 

1. KEY의 중요성

 

데이터 베이스 설계 시 어떤 column을 Primary key로 지정할 지가 굉장히 중요하다.

 

1. 기본키가 없으면 일관성 없는 데이터가 반복적으로 쌓여 쿼리 속도가 느려지고 원치 않는 정보 조회 결과를 가져올 수 있다.

2. 관계형 데이터에서는 반드시 각 행이 고유하게 식별되어야 한다.

3. 기본적으로 Primary Key는 Cluster Index이기 때문에 필요한 데이터를 빠르게 탐색하는 것에 유리하다.

( 단, Database에 따라 PK와 Cluster Index가 동일하지 않을 수 있다. )

4. Database의 실제 저장되는 정렬 순서를 보장할 수 있는 방법은 오직 PK 뿐이다. 

 

 

 

2. KEY 설계시 고려사항

 

 

고객 번호 (인조 식별자)를 사용하는 것이 제일 좋다.

 

 

1. Primary Key 선택 방법

(1) 제공된 정보 중 모든 레코드에서 NOT NULL일 수 있고 Unique한 Column을 찾는다.

(2) 후보 식별자가 없는 임의의 식별자를 만들어서 부여한다. 이것을 인조 식별자라고 칭한다.

 

위 두 가지 방법 중 2번이 거의 주로 사용된다. ( 예시 : client_table의 client_id )

클라이언트가 제공하는 정보는 100% 신뢰할 수 없기 때문에 안정성이 떨어지고 민감한 정보를 사용하게 될 수 있다.

 

 

2. Primary Key의 데이터 타입

(1) 레코드의 발생 가능한 최대 수를 예측해서 설정한다.

(2) 단, 복합키 사용을 고려해야 한다.

 

예 )

학생이 500명이라면 최대 값이 255인 TINYINT를 사용할 수 없다.

그러나 만약 학생이 복합키로 학년, 반, 고유 번호를 모두 가진다면 같은 학년, 반에 고유 번호는 많아봐야 최대 40 정도일 것이므로 TINYINT 타입으로 충분하다.

 

 

3. Auto_Increment (자동 증분)

Primary Key 설정 시 자동 증분 옵션을 선택하면 값을 신경 쓸 필요가 없어 편리하게 사용할 수 있다.

자동 증분을 사용하게 될 경우 중간에 레코드가 삭제되거나 (혹은 실수로 잘못된 데이터를 넣었다가 1초만에 삭제해도) 키 값이 계속해서 증가할 뿐 빈 자리를 채워주지 않기 때문에 이런 걸 견디지 못하는 사람들이 있다.

그러나 Primary Key는 오직 NOT NULL과 UNIQUE라는 속성만 만족시키고 관계만 만들어주면 되는 것이지 다른 부가적인 의미를 부여하는 것은 옳지 않다.

 

 

 

도저히 학생 id가 중간중간 구멍나는 것을 참을 수 없다는 이유로 수동으로 id를 부여하고 있다고 생각해보자.

이 회사에는 3명의 직원이 데이터베이스를 관리하고 있다.

셋이 동시에 업무를 수행하고 있다면 어떻게 id값을 입력할 것인가? 동시성 문제가 발생하게 된다.

매번 서로 눈치게임을 하는 것마냥 업무를 수행할 수는 없을 것이다.

 

 

 

자동 증분 속성을 이용하면 동시성 문제를 해결할 수 있다.

 

 

4. Primary Key에 의미를 부여하지 마라

 

위에서도 계속해서 언급하고 있는 내용이지만 프라이머리 키는 의미가 없는 것이 오히려 좋은 설계일 수 있다.

만약 학교의 반을 생성할 때 프라이머리 키를 반 번호로도 쓰고 (시스템상의) 번호로도 쓰겠다고 생각한다면 굉장히 잘못된 선택일 수 있다.

반 이름이 반드시 숫자일 거라는 보장이 없으며 앞으로 형태나 필요성이 어떻게 변화될지 모른다.

개개인의 고정관념과 고집으로 확장성을 저해시켜서는 안된다.

 

 

5. 필요한가? 싶으면 일단 만들고 나중에 삭제해라

 

클라이언트의 요구사항이 그렇게 구체적이지 않기 때문에 "이런 속성도 필요하지 않을까?"라는 생각이 들면 일단 추가해라.

나중에 삭제하거나 쓰지 않고 방치해도 별다른 문제가 없다.

오히려 하나의 Column으로 여러가지 일을 수행하려고 하는 것은 문제가 된다.