올바른 DB설계

원문출처 : http://codebuild.blogspot.kr/2011/07/20-database-design-best-practices.html

1. 테이블과 컬럼의 이름은 명확한 의미를 가져야하고 일관성이 있어야한다. (예. School, StudentCourse, CourseID…)

2. 테이블 이름에 단수형 이름을 사용해라. 테이블은 개체의 집합을 의미하기 때문에 복수형 이름이 필요없다.

3. 테이블 이름에 공백을 사용하지 마라.

4. 불필요한 접두사, 접미사를 사용하지 마라. (TblSchool 이나 SchoolTable대신에 School을 사용하라)

5. 패스워드와 같은 데이터는 보안을 위해 암호화를 유지하라.

6. 모든 테이블에 정수형 ID 필드를 사용하라. 만약 지금 당장 필요하지 않을 지라도 언젠가 필요하게 될 것이다.

7. 인덱스를 위한 컬럼의 데이터 타입은 정수형 데이터 타입을 사용해라. varchar 컬럼 인덱스는 성능문제를 야기할 수 있다.

8. boolean 값을 위해서 bit 필드를 사용해라, 정수형이나 varchar를 사용하는 것은 스토리지 사용량을 늘린다. 또한 컬럼이름은 “Is"로 시작해라.

9. 데이터 베이스에 접근할 수 있는 별도의 권한을 제공해라, 절대로 admin 권한을 각각의 사용자에게 주지 마라.

10. 꼭 필요한 것이 아니라면  "select * ” 쿼리문을 사용하지 말 것. 성능을 위해서는  "select [required_columns_list]“ 을 사용하라.

11. 응용프로그램 코드의 양이 많다면 ORM 프레임워크(hibernate, iBatis)를 사용해라. ORM 프레임워크의 성능이슈는 디테일한 설정값들로 처리할 수 있다.

12. 대용량 테이블이나 거의 사용되지 않는 테이블은 다른 물리적 저장소로 분리하는 것이 성능에 더 좋다.

13. 대용량 이거나 민감하고, 미션 크리티컬한 DB 시스템이라면, failover clustering, 자동백업, 복제(리플리케이션)등과 같은 복구 시스템과 보안 서비스를 사용하라.

14. 데이터 무결성을 위해서 제약조건(foreign key, check, no null…)을 사용해라. 모든 것을 응용프로그램 코드로 처리하려 하지 마라.

15. 부실한 DB 문서는 악마다. DB 설계를 위한 ER 스키마 및 명령어를 문서화하고, 트리거와 저장프로시져 혹은 기타 스크립트의 경우 주석을 작성해라.

16. 대용량 테이블에서 자주 사용되는 쿼리를 위해서 index를 사용해라, 쿼리 분석 도구를 사용해서 인덱스를 잘 정의해서 사용해라. 페이징 처리와 같은 특정영역의 열를 조회하는 경우, 일반적으로 clustered index들이 더 좋다. 반면 포인트 쿼리의 경우는 non-clustered index들이 더 좋다.([역자] 포인트 쿼리 Point Query : 결과가 하나 혹은 없는 경우의 조회 유형)

17. DB 서버와 Web application 서버는 별도의 물리 서버에 배치해라. 요청 횟수와 프로세스 사용을 감소시키기 때문에 보안과 서버 CPU, 메모리 성능이 향상될 것이다.

18. 이미지 혹은 blob 데이터 컬럼은 자주 조회되는 테이블에 정의하면 절대로 안된다. 그것은 성능이슈를 야기 시킬 것이다. 이 데이터들은 반드시 분리된 테이블에 두어야하고 그 데이터들의 지시자는 조회된 테이블에서 사용할 수 있다.([역자] blob 데이터(BLOB : binary large object) : 대용량의 데이터를 저장할 수 있는 데이터 형식 중 하나로 바이너리 형태의 데이터를 저장하는데 적합하다. 참고 : [MySQL] BLOB, TEXT 데이터 형식)

19. 성능을 최적화하기 위해 필요할 경우 정규화를 해야한다. 비정규화는 데이터를 중복 시키고, 과도한 정규화는 테이블간의 지나친게  join이 발생된다. 둘 모두 성능악화를 야기할 수 있다.

20. DB 모델링과 설계에 가능한 많은 시간을 써라. 반면에 설계 시간을 절약하는 만큼 유지보수와 재설계에 몇 배의 시간이 들게 할 것이다.