ERD 설계하는 중 큰 고민이 생겼습니다 ! ...

Question

현재 DB는 MySQL을 사용하기로 하고 ERD 설계 작업을 진행중 고민이 생겼습니다. 개요캡쳐 사진에 나오듯이 현재 저희 서비스 게시글이 중고와 도움에 관한, 2개의 분류로 나눠져 있습니다. 따라서 처음 설계를 했을 때 게시글이라는 특성 상 비슷한 컬럼 (제목, 본문, 사진) 이 있지만 각 역할이 다르고 서비스적으로도 분리가 되어 있기 때문에 별도의 테이블로 관리를 하기로 설계했었습니다,(서비스상으로 분리가 되어있다는 말은 중고 거래 글을 작성하는 공간과 도움 글 작성하는 공간이 따로 분리되어 있다는 말이었습니다!)이슈이떄, 발생한 고민이 두 테이블을 분리시키는게 아니라 1개의 테이블로 통합 관리하는게 어떤지라는 생각입니다. 이때 1개의 테이블로 관리를 하게 되면 아무래도 둘을 따로 분리하는 것보단 관리에 있어서도 편할거라고 생각이 들었고 조회에서도 좀 낫지 않을까 싶었습니다. 다만, 두 서비스가 유사해보이지만 중복된 컬럼 이외에 겹치지 않는 컬럼이 있다보니 한 개의 테이블로 통합적으로 관리를 하다보면 데이터별로 null이 채워진 컬럼들이 생길것인데 이러한 부분이 괜찮을지?.. 라는 생각이 들어서 고민을 하게 되었습니다. (예를 들면, 중고 거래 글의 경우 공통된 필드(본문, 제목)는 값이 채워지지만 도움 글을 작성할 때만 필요한 채택 여부, 포인트 등은 무조건 NULL로 채워진다는 의미입니다.)따라서 결론은 현재 구조를 유지할지, 1개의 통합 테이블로 관리를 할지 고민입니다.. 두 방법 중 어떤걸 해도 사실 개발에 있어서 큰 문제가 되지는 않을 거 같은데 그래서인지 더 어렵습니다 ..ERD 설계를 함에 있어서 물론 출시를 예정으로 하는 서비스는 아니지만 어느 정도 확장성을 고려해서 설계를 해야 하는지 .. 기준을 어떻게 잡고 넘어갈지 헷갈려서 경험자분들의 조언을 듣고 싶습니다 !!

만숙이바보 · Answer

말미에 기술하신 확장성을 고려한다면 정규화를 원칙으로 진행하시는게 맞습니다만비정규화시 말씀하신 빈 값으로 채워질 컬럼들의 데이터가 파편화가 심하지 않아 조회 시 성능이 크게 문제가 되지 않는다면 비정규화된 테이블로 확장해 나가는 것도 틀린 답은 아닙니다.

dadaqwe · Answer

null인 데이터가 null로 저장되는게 문제가 있을까요 ? 개인적으로 저는 문제가 없어보입니다.그러나 게시판이 두개라면 확장성을 위해 두개로 만들 것 같습니다. 필드 구분을 통해 게시판을 구분하고 하나의 테이블로도 통합이 가능하겠지만 장기적으로 봤을때 필드 확장성에 문제가 있지 않을까요 ?그리고 혹시라도 통합을 하시려고 생각하시면 추상화가 도움이 될 것 같습니다.

초무쿤 · Answer

EAV(Entity-Attribute-Value) 모델이라고 동적으로 설계 빙법도 있긴 한데요. 적합상 여부는 고민을 좀 해보셔야됩니당.장점: 태이블수정 없이 optional attribute 확장이 가능함단점: 개발이 복잡해짐 성능상 손실.개발팀 db 이해도가 고려되어야함.

장독깨기 · Answer

처음 진입하시는 분들이 좀 보면 조금이라도 중복 되는 꼴을 못 보고 자꾸 합치려고 합니다. ㅎ이게 뭔가 효율적이라 생각하는거 같긴 합니다만,...근데, 가만 보면 중복되는 컬럼은 제목과 내용 뿐입니다.지금은 도움과 거래 테이블 뿐인데요, 제목과 내용이 들어가는 다른 목적의 기능이 생긴다면,이런 기능이 자꾸 늘어난다면, 그래도 다 합칠 것인가요.게시판은 게시판이고 중고거래는 게시판이 아닙니다. 업무가 목적이 다른거에요.별도로 분리하는게 맞습니다.그리고, ERD TOOL 은 https://www.erdspace.com 여기 한 번 이용해보세요.테이블 많아지고 그러면 관계선이 복잡해서 정신 없을 것입니다.erdspace 는 관계선 위치를 조정할 수 있어서 깔끔하게 정리할 수 있습니다.물론, 기본적인 기능들은 다 갖추고 있고, 부가적인 기능도 꽤 있습니다. :)

르매 · Answer

한 가지 궁금해 하시는 부분의 답을 얻지 못한 것 같아 첨언 합니다.일단, 두 테이블은 하나로 합치기에 성격이 달라 분리해 두는 것이 맞습니다.다만, 대부분의 속성이 동일하고 일부 다른 속성이 있는 경우 테이블을 하나로 통합하는 것이 혹시 비정규화가 아닌가? 라는 궁금증이 있으신 듯 하네요.결론부터 말씀드리면.. 두 테이블을 분리하던 통합하던 둘 다 정규화의 영역에 있습니다.이런 걸 슈퍼타입과 서브타입이라고 불러요.그리고 실제 테이블로 구현하는 것을 물리 모델링이라고 하는데, 슈퍼타입-서브타입을 설계하는 방법은 세 가지가 있습니다.가장 흔한 예가 직원을 내근 직원과 외근 직원으로 구분하는 예입니다.각각의 테이블로 완전히 분리하기 내근 직원 테이블과 외근 직원 테이블로 분리하는거죠. 이런 걸 One to one 타입 또는 Identity 라고 부릅니다.1개의 테이블로 통합하기 내근 직원과 외근 직원을 한개의 테이블로 통합하고, 구분 컬럼을 추가해서 이 레코드가 내근인지 외근인지 구분하게 합니다. 이 때 공통 속성이 아닌 컬럼은 NULL을 허용하게 만듭니다. 이런 건 Single 타입 또는 Rollup이라고 해요.슈퍼타입과 서브타입을 각각의 테이블로 만들기 직원이라는 슈퍼타입 테이블을 만들고, 직원 테이블과 1:zero or 1로 조인할 수 있는 서브타입 테이블인 내근 직원, 외근 직원 테이블.. 이렇게 3개의 테이블을 만듭니다. 이때 공통 속성과 구분 값은 직원 테이블에 컬럼으로 만들고 공통이 아닌 컬럼만 각각 내근 직원 테이블과 외근 직원 테이블에 만들죠. 이런 건 Plus 타입 또는 Rolldown이라고 부릅니다.위의 세 가지 방법 모두 정규화이고 물리적으로 구현하는 정형화된 방법들입니다. 다만, 기획 의도나 테이블을 조회하는 패턴에 따라 어떤 방법을 선택하는 것이 옳은지가 달라질 뿐입니다. 이때 선택의 기준은 주로 &#34;성능&#34;이 되겠죠.본문에 나오는 예는 서로 성격이 다른 테이블이라 여기에는 해당하지 않지만, 다른 상황에서 참고해 보세요.

ERD 설계하는 중 큰 고민이 생겼습니다 ! ...

5개의 답변

기술 목록