database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
Oracle
Informix
Sybase
ㆍMS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
MS-SQL Q&A 5773 게시물 읽기
No. 5773
테이블 설계에 조언을 구합니다.
작성자
시월애
작성일
2010-10-07 05:33ⓒ
2010-10-07 05:34ⓜ
조회수
7,305

개발자들끼리 처음으로 그룹웨어 데이터베이스를 설계하고 있는데 서로 경험이 달라서 의견 충돌이
많아 고민입니다.
아래의 경우 어떻게 설계를 하는 것이 좋은 지...
참조 무결성을 유지하면서  조회 성능을 좋게 하고 싶은데...의견을 구합니다.

 

그림1:

-사원정보 : 사원번호(pk)
-근태정보 : PK(날짜 + 사원번호(FK))

 

근태정보에서 사원번호를 FK로 가져옵니다. 저는 (날짜 + 사원번호)로 하면 데이터 중복이
안일어나니까 (날짜 + 사원번호) 이렇게 두개의 컬럼을 결합해 기본키로 잡고 가려고 주장하고 있습니다.
조건 절의 경우 where 날짜 = '' and 사원번호 = ''
또는 where 날짜 = '' 또는 where 사원번호 = ''
이렇게 될것으로 생각하고 있습니다.
결합기본키의 경우 기본적으로 생성시 앞 순서인 날짜에만
클러스터인덱스가 생성되는 것 같았습니다.
그래서 둘다 조건절에 들어갈 경우나 날짜만 검색시에는 생성된 index를 사용하는데
사원번호만을 검색할 경우는 테이블 스캔을 하더라구요.

그래서 결합기본키는 성능이 안좋으니 아래처럼 하자며 그림2가 나왔습니다.

 

그림2:

-사원정보 : 사원번호(pk)
-근태정보 : PK(근태번호) , 날짜 , 사원번호(FK)

 

기본키는 그냥 근태번호라는 걸 생성하고 검색에 쓰이는 날짜나 사원번호는
일반 속성으로 넣고 조회성능을 위해 그 속성들에 인덱스를 걸자는 취지지요.
근데 근태번호는 고유키이긴 한데, 범위검색에 자주 쓰이는 속성은 아닌것 같아서요.
어찌 하는 게 좋을 까요.

제 경우는 필요에 따라 FK를 가져온 것을 기본키에 포함 시키기도 하구 그냥 일반속성으로 넣기도 하고 그러는 데 반해
다른 개발자분의 경우 FK로 가져온 것은 위처럼 결합 기본키는 사용을 안하시고 그냥 일반속성에 넣고 기본키는 테이블마다 따로 생성을 하면서 디자인 하는 경향이거든요.

서로 다르니까 애로사항이 많습니다.

어떻게 서로 중간지점을 찾을 수 없을런지...도움말 부탁드립니다.

이 글에 대한 댓글이 총 1건 있습니다.

1. 근태정보의 PK는 (날짜, 사원정보)  또는 (근태번호) 어느게 맞느것인가?
  근태정보의 PK를 받는 자식 테이블이 존재하느냐에 따라 결정됩니다.
  자식테이블 존재시 근태번호라는 신규 컬럼을 만드는게 대부분 효과적이고
  그렇지 않다면 (날짜, 사원정보) 로 하는게 유리합니다.
 

2. (날짜, 사원정보) 로 PK를 할때 사원번호로만 검색시 테이블 스캔을 한다
  기본값으로 클러스터인덱스가 (날짜, 사원정보) 로 설정되기에 날짜가 검색조건에 들어가면
  인덱스를 잘 타지만 사원번호로만은 당연 테이블스캔(정확히는 클러스터드 인덱스 스캔) 합니다.
  그럴때 사원정보 컬럼에 추가로 인덱스(넌클러스터드) 를 추가해 주어야 합니다.

3. 만약 근태번호를 새로 만들어 PK지정시 범위검색에 자주 사용 안되서 클러스터드 인덱스
    가 너무 아까운거 아닌가?

    한 테이블에 클러스터드 인덱스는 1개만 사용가능하고 또한 범위검색과 포인트 검색에 모두 장점을
   가지고 있기 때문에, 자주 쓰이지 않는 근태번호에 CI 는 너무 아깝기도 합니다.
    그럴 경우 PK를 만들때 기본값인 클러스터 대신 넌클러스터드로 만들면 됩니다.
    거의 90% 이상 PK는 넌클러스터드로 하는게 나중을 위해서 더 유리하기도 합니다

4. 추가설명
  PK를 (근태번호)로 하든 (날짜, 사원번호) 로 하든 클러스터드 인덱스는 (날짜, 사원번호)로 하는게
  좋습니다. 사용패턴이 날짜로 검색하는 게 많은 것 같은데 범위 검색에 강한 클러스터드이기 때문입니다
  또한 이렇게 날짜 순으로 차곡차곡 쌓이면 테이블 조각화 현상도 적어져서 관리와 성능에 보다
  유리해지는 이점도 생깁니다.

100% 맞는 설명은 아니지만 이해를 돕기 위해 생략한 부분도 있습니다
도움이 되었으면 좋겠네요.
  

추리님이 2010-10-08 09:31에 작성한 댓글입니다.
이 댓글은 2010-10-08 09:32에 마지막으로 수정되었습니다. Edit
[Top]
No.
제목
작성자
작성일
조회
5777고급 쿼리 질문입니다. [1]
성진영
2010-10-11
6714
5776user 가 존재한다면 삭제하는 방법은? [1]
용세중
2010-10-11
5988
5774sp 생성 중 조언을 구합니다. ㅠㅠ [2]
조문수
2010-10-07
7724
5773테이블 설계에 조언을 구합니다. [1]
시월애
2010-10-07
7305
5772간단한 쿼리 문 [2]
모이
2010-10-06
6080
5771select * from [테이블명] error 해결책좀 알려주세요.
김재호
2010-10-06
6578
5770SQL Server2000 create table 구문 오류 [2]
김지명
2010-10-05
7013
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.017초, 이곳 서비스는
	PostgreSQL v16.2로 자료를 관리합니다