http://m.11st.co.kr/products/m/1116798927
책 후기
db설계를 하면서 신경써야 할 부분에 대해서 잘 정리한 책이라고 느꼈다. db설계 시
하나의 테이블이 하나의 주제를 나타내도록,
가능하면 무결성을 보장하도록,
최소의 중복 데이터를 저장하도록 하는 것
같은 관점으로
바라보면서 더 나은 설계를 할 수 있겠다고 생각한다.
제목대로 쉽게 설명하기 위해 어려운 용어를 쓰지 않았다는 점이 느껴졌다.(그럼에도 쉽게 읽히지는 않지만)
잘 와닿지 않던 부분도 있었다.
관련자 인터뷰, 예비 필드 목록 작성, 필드명세 작성 등에 대한 이야기가 있었는데, 그렇게 까지 db설계 해본적은 없어서 필요성이 크게 와닿지는 못했다. 더 크고 복잡한 서비스이면 필요할 듯도 하다.
정리
테이블 설계
이상적 테이블의 요건 몇 가지가 있다.
- 1)필드들이 모인 테이블이 하나의 주제를 나타냄
- 2)중복 데이터 최소화
- 3)다중부분 필드, 다중값 필드 제거
- 4)다른 필드로부터 계산된 필드 제거
물론 db를 통해 서비스가 잘 수행될 만큼의 데이터들이 저장되어야 한다는 것은 기본조건이다.
우선 4)다른 필드로부터 계산된 필드는 지양해야 한다는 건 경험적으로 공감했다.
다른 필드 수정마다 계산된 필드까지 같이 수정해야 되는 일이 발생하면 복잡해진다.
실제로 우테코 지하철 미션을 하면서 지하철 노선 구간들의 정렬을 위해 db에 다음 구간에 대한 필드(next)를 저장해 본적이 있다.
이때 다른 필드 수정 시 next필드가지 동시에 수정하는 건 번거로운 일이고, 서비스 로직이 db저장에 의해 영향받아 좋지 않았다.
ex) 마지막 구간일 경우, 중간 구간일 경우, 처음 구간일 경우에 db저장이 다르니 서비스 로직도 이를 나눠주어야 했다.
3)의 다중부분 필드, 다중값 필드들은 그렇게 까지 신경쓰던 요소가 아니라 더 재미있게 읽었다.
다중부분 필드는 의식하지 않으면 인지하기 어려울 듯 하다.
예를 들어 상품번호라는 컬럼에 abcd1234 가 저장되는 식으로 설계되는게 부자연스럽지는 않다.
하지만 abcd부분은 다른 컬럼으로 분리해서 저장해 like검색을 안해도 되도록 만들 수 있겠다.
다중값 필드는 데이터에 , 같은 delimeter로 여러 정보를 저장하는 방식이기에 인지하기는 쉬울 것 같다.
다만 그것들을 테이블로 분리하는 방법은 알아두면 좋을 것 같다.
나도 책을 읽지 않았다면 다른 컬럼들로 평탄화하는 식으로 설계했을 수도 있을 것 같았다.
테이블의 종류
- 데이터 테이블(일반적인 테이블)
- 부분집합 테이블
- 연결 테이블
- 검증 테이블(룩업 테이블)
데이터 테이블이나 연결 테이블은 어느정도 아는 개념이었지만
부분집합 테이블, 검증 테이블은 이런 유형으로 분류될 수 있다고 생각해보지 못했는데 책을 보고 알게 되었다.
부분집합 테이블은 분류,카테고리를 세분화해서 저장할 때 고려하면 될 듯하다.
업무 규칙을 검증 테이블을 통해 보장하는 방식도 있다는 건 새로웠다.
지금까지는 다 서비스 로직 차원(응용 프로그램 지향)에서 데이터를 조작했지 이렇게 db차원에서도 필드제한을 시킨 적은 없었다.
검증 테이블은 필드에 들어갈 정보 다른 테이블에 저장하고 참조하는 식으로 데이터 무결성을 구현한다.
나는 그래도 서비스 코드에서 이런 검증을 하는 걸 선호하지만, 정말 제한시키는 게 중요한 데이터라면 이렇게 db차원에서 검증하는 방법도 좋겠다고 생각했다.
