검색은 주로 무엇으로 할건지, cardinality 는 어떨지 등등을 고려해야겠죠..  실제 조인과 where 조건검색은 거의 동시에 처리됩니다.

인덱스를 얼마나 효율적으로 쓸 수 있을지가 중점이 되겠죠.

일단 정규화 개념에서 말씀을 드리면,

지우개님께서 올리신 PERSON_TB은 제 1정규화 내용입니다.

즉, NULL데이타를 포함하여 반복되는 테이블(PERSON_TB)의 필드(휴대폰,집전화)를  제거한뒤, 기본 테이블의 기본키(사원번호-PK)를 추가해서 새로운 테이블(CONTACT_TB)을 생성하고 기존의 테이블(PERSON_TB)과 1:N의 관계(당연히 관계형 데이타베이스니까..^^)를 형성하는 것입니다.

그러므로 지우개님께서 분리한 테이블은 올바른 분리가 되겠습니다.

그렇다면 지우개님께서 궁금해하는 부분에 대하여 간단히 설명을 하자면, RDBMS(예.. 오라클, DB2, MS-SQL...등등)는 데이타 테이블을 SELECT할때 레코드나, 필드 단위로 SELECT를 하는 것이 아니라(사람이 보기에는 그렇지만) 블럭(BLOCK)단위로 SELECT를 합니다.

다음의 가정하에 설명을 드리겠습니다.

- RDBMS의 입출력 블럭 단위가 2Kb라고 가정

- PERSON_TB  1개의 레코드(사원번호,이름,부서)의 사이즈가

  20byte이고  PERSON_TB의 총 레코드가 10만 건이라고 가정

- CONTACT_TB  1개의 레코드(사원번호,종류,연락처)의 사이즈는

  20byte이고 CONTACK_TB의 총 레코드는 2만건이라고 가정

제1정규화 한 테이블을 조인(JOIN) 하여 SELECT 할때는

PERSON_TB을 풀스캔, CONTACT_TB을 풀스캔, 하여 인덱스값으로

맞는 조건을 찾아서 뿌려줍니다.

PERSON_TB 풀스캔시 총 입출력 내용은

   20byte * 10만 = 2,000,000byte = 대략 2,000Kb

CONTACK_TB 풀스캔시 총 입출력 내용은

   20byte * 2만 = 400,000byte  = 대략 400Kb

합하면 2,400Kb 입출력 블럭 횟수는 1,200번

제1정규화를 위반한 PERSON_TB(PERSON_TB + CONTACK_TB)을

SELECT 할때는 입출력 블럭 횟수는

 (20byte + 20Byte) * 10만 = 4,000,000byte = 대략 4,000Kb = 2,000번

결과는 거의 두배의 속도 차이가 나게 됩니다.

RDBMS의 퍼포먼스는 CPU나 메모리 부분이 아니고 데이타베이스로

접근하여 입출력하는 부분입니다.

* 추가설명

   RDBMS의 데이타 찾는 방법은 SELECT하고자 하는 데이타의 내용을

  메모리로 올린뒤  조건에 맞는 부분을 찾아서 뿌려주는 것입니다.

  CPU연산속도가 아무리 늦어도 I/O하는 부분보다는 빠르겠죠..? ^^;

  더구나 조건에 맞는 대상을 검색할때는 모든 레코드의 필드를 검색하

  는것이 아니라 INDEX 필드가 있다면 더욱 빨라 지겠죠.. ^^;

이상 제가 알고 있는 지식하에 설명했습니다.

혹시 제가 설명한 부분이 틀린부분이 있으면 지적하여 주세요

겸손하게 받아 드리겠습니다. 저두 이제 디비 공부를 막 시작해서

좀 허접합니다... o(_._)o 꾸벅

참 어려운 부분임니다.

향후에 어떻게,어떤항목들이 늘어날것인지,어떻게 쓰일것인지 미리예측한다면 모르겟지만,,,,

만들어놓고 기본구조를 다시바꿀수도 없고,,,

흑.. 실제로 모델을 테이블로 구현한다면 아마 지금까지 고민하셨던 모든것이 바뀔껍니다. 조금의 중복을 허용하고 테이블을 줄인다는 입장에서 생각해 보면 무엇을 어떻게 중복시킬것인지 실마리가 잡히실 것입니다.

물론 개념적인 설계과정에서는 기본적으로 쪼개는 과정이 필수지요. 하지만 쪼갤때는

1. 테이블의 키가 정말로 다른 속성을 결정하는지,

2. 다른 테이블로 키를 묶었을때에 묶은 테이블의모든 속성을 결정할 수 있는지도 보아야 합니다.

다시 말이 돌아가는것 같지만, 실제적인 설계에서는 논의한것은 정말 무의미 합니다. 테이블을 쪼개면 조인이 늘어나기만 하고 쿼리도 어려워 지니까..

정규화 / 비정규화

개념적인 것보다 프로그램을 개발하는 입장에서 보면  너무 정규화하게 되면 테이블이 암호화가 되어 버릴수 있습니다. 정당한 선에서 정규화가 필요하다고 봄.

죄송하지만, 정규화/비정규화를 논할 테이블 구조는 아닌 듯 합니다.

만약 부서 테이블이 있고, SELECT 시 쿼리를 간단히 하기 위해 부서 연락처를 PERSON_TB에 둘까 말까를 고민한다면, 정규화/비정규화를 논하는게 되겠는데, 위의 고민은 그게 아니라 있을지도 없을지도 모르는 데이터를 가지고 논하있어서 말이죠.

(정규화 이야기를 할 때는, functional dependency, trivial, non-trivial 이런 개념이 있어야 하는데 없어 보인다는 것이죠)

암튼 결론을 말씀드린다면 위의 상황이라면 테이블을 나눌 필요까지는 없을 듯 보입니다.

제가 잘못된 생각이라면 알려주세요~ 공부한지 오래되서 다 까먹었거든요 ㅎㅎ;

ps. 어라. 근데 적고 났더니, 11월에 작성되었던 글이네요.