데이터베이스 설계에서 이상적인 스키마 작성 기준이 있나요?
데이터베이스 설계에 관하여 공부를 하고있습니다.
간단하게 이상적인 DB 설계에 대해 궁금합니다.
예를 들어, 호텔 전산시스템을 구축하려 할때 어느 부분부터 생각하고 설계해야 이상적인 설계가 될까요? ( 개개인 마다 차이가 있겠지만, 의견 부탁드립니다! )
답변자에 따라 여러 기준을 제시하겠지만
저는 다음과 같습니다.
1. 전체적인 DB의 자원 사용률에 대한 예상
당연하게도 데이터가 많으면 DB에 할당된 자원을 고려해야합니다.
담아야할 물은 10리터인데, 1리터짜리 물통을 쓰면 안되겠죠?
이것은 서버의 성능과 관계가 있습니다.
구축하려는 DB가 얼마만큼 데이터를 쌓을 것인가, 얼마나 많은 트랜잭션이 발생할 것인가를 생각하고
걸맞는 넉넉한 스토리지 공간과 메모리를 가진 서버가 필요하겠죠.
요즘 나오는 서버는 어느정도 성능이 보장이 됩니다만, 하루에도 몇만, 몇십만 열의 대용량 데이터를발생하는 DB를 다루게 되면 반드시 고려해야 됩니다.
2. 스케일링에 대한 고려
한 테이블에 필요한 컬럼데이터를 다 때려박고 설계할지,
관계 키를 가진 여러개의 테이블을 조인하는 구조로 설계할지 고민해봐야 됩니다.
보통은 관계형 DB라는 개념이 성립되면 데이터의 비즈니스 구조와, 업무단위 레벨을 고려한
테이블 설계를 하게 됩니다. 한 테이블에 모두 때려박는 설계는
확장성과 퍼포먼스를 위해서라도 지양해야 됩니다.
3. 데이터의 용도에 대한 스키마 분리
2와 관련이 있는데, 만약 객실 사용과 예약에 관한 데이터를 다루는 테이블 구조를 만든다고 생각해봅시다.
고객정보가 있을 것이고, 예약정보가 있을것이며, 고객이 투숙하고 있는 동안에 관리하는 기타 클레임 데이터도 발생할 것입니다.
고객정보는 기초정보로서 가장 적은 데이터가 발생할 것이고
그 다음 예약정보가 더 많이 발생하겠죠?
그리고 1건의 예약정보에는 관련된 사용 데이터가 더 많이 발생할 것이므로
고객정보 < 예약정보 < 사용정보의 순으로 사용정보가 결정될 것입니다.
그렇다면 이 정보들은 각각 별도의 테이블로서 설계하고 서로 연관관계를 가질 수 있는 외래키를 선언해주는게 보통의 설계방법일 것입니다.
4 . 대용량 데이터의 발생 여부 고려
이것도 2와 관련이 있는데요, 만약 하루에도 수만건이 발생하는 데이터라면 1개의 DB에 모든 데이터 구조를 설계하는거보다는 그런 대용량 데이터가 발생하는 DB는 따로 설계하는 것이 좋습니다.
그러면 복수의 DB 구조가 되므로, 이를 연계하는 방법에 대해 고민하게 됩니다.
이때부터는 전체적인 시스템 아키텍쳐를 고려해서 설계하게 되는데, 인터페이스에 관한 고민을 하게 됩니다.
예를 들어 REST API방식으로 데이터를 연계할지, mysql의 경우 FEDRATE나 오라클의 경우 DBLINK를 만들어서 연계할지, 단순 VIEW SCRIPT로도 충분할지 등등 요소를 고려하게 됩니다.
5. 테이블정규화, 칼럼 정규화
명명에 관한 명확한 룰을 정하는 것이 좋습니다.
단순한 구조의 DB라면 모르겠지만 복잡하고 다단한 구조의 설계가 된다면
처음부터 명명 규칙을 잘 정해두고 설계하는 것이 좋습니다.
예를 들어 어떤 설정에 관한 테이블이 여러 묶음이 나온다면
PREFIX로서 테이블명을 CFG_USER_INFO
일반적인 데이터가 생산된다면 TB_STAT_LIST
이런 식으로 접두어를 구분해주는 것이 좋으며
SUFFIX로서 LIST, VIEW, INFO, LOG 등을 써서 목록인지, 단순보기인지, 특정정보를 보려한 것인지 등등
식별성을 부여하는게 좋습니다.
그리고 당연하겠지만 가급적 단어도 영단어를 쓰시는게 좋습니다.
고객번호라는 칼럼이 있다고 칩시다.
GOGAEK_NO를 쓰는게 좋을까요, 아님 CLIENT_ID를 쓰는게 좋을까요?
그리고 또한 식별성을 부여하기 위한 일환으로 여러 단어가 혼합된 칼럼명이라면
위 예를 보신대로 _를 사용해서 보기좋게 구분하는 것이 좋습니다.
5. 데이터 타입에 대한 고민
한개의 칼럼이 숫자만 입력 받는것인지, 숫자와 문자 모두 입력받는것인지 고려해서
데이터 타입을 결정해야 됩니다.
이게 한두개면 모르겠는데, 엄청나게 많이 쌓이면 그때는
데이터를 호출할때 퍼포먼스와도 관계가 있습니다.
어떤 관계가 있는지는 설명이 길어지므로 생략하겠습니다.
이 외 고려할 요소가 많지만 원칙은 단 하나로부터 출발합니다.
"만드려는 시스템의 사이즈와 용도, 업무 구조를 먼저 철저히 파악하고
최대한 간결하고 간단한 구조를 지향해서 설계하되 확장성을 염두에 둔다."
는 것입니다.
