테이블 하나로 구성을 하느냐 나누느냐 하는 문제는 각 자료들간의 연계성에 따라 달라 지는 것입니다. 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 설계란게 정말 어려운거 같군요.
> 동호회 사이트 하나 만들려다 늙고 있슴다. -__-
|