데이터베이스 설계의 기본원리2

1. 모든 테이블은 반드시 서버에 있어야 한다? 

만약 코드에 관련된 테이블들이 변경횟수가 매우 적다면 구태여 서버에 두려고 할 필요는 없다. 클라이언트에 복사해서 사용하는 방법을 적극적으로 검토한다. 특히, 우편번호와 같이 레코드 수가 테이블을 빈번히 사용해야 하는 경우라면 클라이언트 에 복사본을 두고 작업하는 것이 훨씬 능률적이다. 

2. 필드의 추가가 고려되는 경우

- 자주 계산되는 필드 계산필드는 View 테이블이나 델파이의 Calculated Field 등을 이용하는 경우가 많지만 계산에 의한 부하가 많은 경우에는 아예 계산된 필드를 생성한다. 이는 기 존에 계산된 데이터가 필요한 경우에도 도움이 된다. 

- Flag를 이용하여 조인 등의 시간을 절약할 수 있는 경우 미수요금이 있는 지 없는 지를 검사해야 할 경우. 전체 입금과 부과금을 계산하여 마이너스인지를 항상 점검해야 한다면 Flag필드를 만들어 주는 것이 좋다. 특히, 이러한 조건이 Case문과 같이 다양한 값을 가져야 할 때 효과적이다. “최근 1개월 이전에 물건을 산 적이 있는 사용자”에 대한 작업을 한다고 가정하면 그 효과는 극적이다. 매 레코드 마다 이것을 계산하는 것과 미리 Flag를 사용하여 작업하는 것의 차이는 엄청나게 크다. 

- 날짜 필드의 중복 Flag의 경우와 동일하다고 볼 수 있다. 만약 매주 시작되는 유료강좌가 있다고 가 정하고 사용자가 이것을 등록하기 위한 프로세스를 생각하자. 이때, 각 주 별로 통 계를 내거나 하는 프로세스라면 날짜를 통해서 몇 번째 주인지를 항상 계산하는 것 은 효율이 없다. 

3. Index 설계 시 유의 사항

- 한 Field에 입력될 내용의 종류가 적으면 그 Field는 Index를 만들지 않는다. 예를 들면 성별 Field와 같은 경우이다. 

- Data의 양(=Record 수)이 적으면 Index를 만들지 않는다. 

- 변경이 많은 Field는 Index를 만들기를 조심한다. 

- 변경이 적고, 검색이 많은 Field는 Cluster 생성을 고려한다. 

- 변경이 주로 되며 Batch작업이 많은 Table의 경우는 Index를 만들지 않는다. Batch 작업 전에 인덱스를 삭제하고 종료 후에 인덱스를 생성하는 방법도 고려할 수 있다 

- 결합 Index를 생성할 때는 검색이 많은 Field를 항상 먼저 쓴다. 

- 결합 Index를 생성할 때는 인덱스 효율이 좋은 필드를 먼저 쓴다. 내용의 종류가 많은 필드가 인덱스 효율이 좋다. 

- 하나의 Table에 5개 이상의 Index를 생성해야 하는 경우라면 설계를 재검토 한다. 

- 빈번하게 Join을 할 필요가 있을 때, 해당 Field의 Index를 생성한다. 

- Index가 가해지는 필드는 가능한 Null값이 없어야 한다. 

4. Join 시 유의 사항

- Table Join 시에는 Record의 수가 적은 것부터 Join한다. 

- 다량의 Table과 다중 Join이 필요할 시에는 Cluster를 생성한다. 

5. 검색 시 필드는 연산하지 않는다

- 인덱스가 적용되지 못하는 경우 Select * from Table1 where SUBSTR(Name, 1, 2) = '류' Select * from Table1 where Score * 10 >= 90 

- 인덱스가 적용되는 경우 Select * from Table1 where Name Like '류%' Select * from Table1 where Score >= 90 / 10 

6. 계산이 필요한 숫자형 필드는 0을 디폴트로 지정한다

Null Data로 인해 Sum이나 Avg와 같은 숫자 연산이 되지 않아서 생기는 논리적이 오류를 방지할 수 있다. 쿼리문을 통한 결과값을 확인하는 조회의 경우에는 큰 문제가 되지 않으 나, 이것을 토대로 계산을 하는 “Stored Procedure” 등을 작성할 경우에는 그 과정에 대한 가시성을 확보할 수가 없어, 찾기 어려운 에러를 유발하게 된다.