mysql 테이블 설계시, 세세하게 정보를 나누어서 테이블을 여러개 만들어야 하는 이유가 모죠?
책을 보다보니 디비설계시 한테이블에 많은 정보를 넣지 말고
여러개의 테이블로 나누어서 만들라고 하던데요
제가 보기엔 괜히 더 복잡하고 쿼리문 작성할때도 힘들고 하던데
왜 그래야 하나요?
사용자가 1만명 미만이라고 해도 여러개의 테이블로 나누어야 할까요?
예를 들어 제가 생각하는 테이블)
테이블명 : member
id,이름,성별,전화번호,주소,혈액형,메모
책에 있는데로 만들어본 테이블)
테이블명 : member
id,이름,성별
테이블명 : member_blood
uid, 혈액형
테이블명 : member_addr
uid, 주소,전화번호
테이블명 : member_memo
uid,메모
위와 같은데요? 괜히 쓸데없이 쿼리글자만 엄청 많이 늘어날것 같은데. 왜 이렇게 나누라고 한걸까요?
안녕하세요??
DB 테이블 설계에 대해서 질문주셨는데
일단 일반적으로 DB설계 할때에는 정규화로 통해서 설계를 하게 됩니다.
질문 주신 내용과 같은 테이블일경우 질문자님께서 생각하신 테이블로 만들어도 전혀 무관합니다.(데이터양이 100만건 넘어도요)
아마 보고 계신 책에선 어떤 예제를 위해서 그렇게 테이블을 만들지 않았나 추측됩니다^^
앱의 최종적인 형태가 확장성이 아예 없다는 가정이라면 데이터베이스를 정규화를 하지 않고 쓰기 편한 형태로만 설계해도 전혀 상관이 없지만 RDB 특성상 추후 앱을 확장해야하는 경우 스키마를 변경하기가 굉장히 힘들기때문에 혹시 모를 스케일 업에 대비하는 거죠.
말씀하신대로 하나에 다 몰아넣어도 되지만 혹시나 각 서브 테이블이 가진 데이터 한개의 레코드마다 언제 만들어졌고, 또 언제 수정됐는지 기록해야하거나 같은 타입의 데이터가 한 멤버에게 여러개가 들어갈 수 있다면 말씀하신 방법이라면 굉장히 비효율적이게 되겠죠.
간단하게 예를 들면 유저에 딸린 메모가 코멘트 식으로 여러개를 달 수 있는 구조라면 memo1 memo2 ... 이렇게 칼럼을 계속 만들어야하죠. 하지만 책에 나온대로 설계하면 메모를 무한정 넣어둘 수 있겠죠.
