테이블 하나로 구성을 하느냐 나누느냐 하는 문제는 각 자료들간의 연계성에 따라 달라 지는 것입니다. DB modeling 에 절대적으로 영향을 미치는 인자 중의 하나는 디비의 사용목적입니다. 그 구성과 앞으로의 관리성도 고려를 해야겠지만 어디에 어떤 용도로 사용할 것인가가 가장 중요하다고 생각합니다.

그런 의미에서 테이블을 나눌것인지 말것인지를 결정해 보시기 바랍니다.

다음으로 인덱스 생성에 대한 policy 입니다. 인덱스 생성은 Query 의 속도를 빠르게 하기 위한 목적입니다. 그러므로 Query 를 줄때에 search, retrieval 을 할 경우에 어떤 attribute 의 순서에 따라서 또는 어떤 attribute 를 기준으로 search 를 하느냐가 가장 중요한 항목 같습니다. 그런 항목을 중심으로 index 를 만들면 될 것 같습니다. index 부분은 DBMS 가 어떤 식으로 index 를 이용하는지 책을 읽어 보시고 생성하시기 바랍니다. 잘못 만들면 공간만 차지하는 무용지물의 인덱스를 만들 수 있습니다.

> 무작정 질문드립니다.

>

> 관리자를 포함하는 각 레벨(userlevel)의 회원을 아래와 같이 테이블 하나로 구성하면 어떨까요?

> (이건 공개된 소스의 테이블 스키마임다.)

>

> CREATE TABLE member (

> uid int(10) unsigned DEFAULT '1' NOT NULL auto_increment,

> name varchar(12) DEFAULT '' NOT NULL,

> id varchar(10) DEFAULT '' NOT NULL,

> passwd varchar(30) DEFAULT '' NOT NULL,

> birthyear smallint(5) unsigned DEFAULT '0' NOT NULL,

> birthmonth tinyint(3) unsigned DEFAULT '0' NOT NULL,

> birthday tinyint(3) unsigned DEFAULT '0' NOT NULL,

> calendar enum('S','L') DEFAULT 'S' NOT NULL,

> sex enum('M','F') DEFAULT 'M' NOT NULL,

> email varchar(60),

> homepage varchar(60),

> job enum('officeman','business','specialist','housewife','student','etc'),

> cp1 char(4),

> cp2 char(4),

> cp3 char(4),

> Haddr varchar(255),

> Hzipcode1 char(3),

> Hzipcode2 char(3),

> Hphone1 char(4),

> Hphone2 char(4),

> Hphone3 char(4),

> officename varchar(255),

> teamname varchar(255),

> Oaddr varchar(255),

> Ozipcode1 char(3),

> Ozipcode2 char(3),

> Ophone1 char(4),

> Ophone2 char(4),

> Ophone3 char(4),

> poll1 tinyint NOT NULL,

> signdate int(10) unsigned DEFAULT '0' NOT NULL,

> userlevel enum('0','1','2') DEFAULT '1' NOT NULL,

> PRIMARY KEY (uid)

> );

>

>

> 회원의 수가 많아지면(어느 정도?) 그만큼 속도가 느려지지 않을까요?

> 쬐금 걱정되는 부분이라서 잘 몰르지만 별도의 인덱스 테이블을 만들면 어떨까 합니다.

> 책에서 읽었거든여..

> 근데 맨날 이거 생각하다 날밤 새고 있습니다.

> 인덱스 테이블 스키마에 구성에 대한 조언 좀 주세요.

>

> DB 설계란게 정말 어려운거 같군요.

> 동호회 사이트 하나 만들려다 늙고 있슴다. -__-