데이터베이스 설계 단계에서 고민이 있습니다

Question

현재 ERD 설계중인데 고민이 생겼습니다.데이터베이스 컬럼에 다중값이 들어갈 때 어떻게 설계하시는지 궁금합니다. 배열로 저장하기 -> 수정이 필요한 경우가 되게 번거롭기도 할 거 같고 데이터로써의 관리가 어려울거같습니다JSON으로 저장다중값을 관리하는 테이블을 생성하고 유저와 매핑되는 중간 테이블 생성편한 부분은 2번일거같은데 저장되는 다중데이터가 코드로 관리되어야 한다는 전제조건이 있긴 합니다. 이런 경우 3번이 최선일까요예를 들어, 사람인이나 잡코리아처럼 이력서 등록에서 기술스택을 등록할 때 1명에 있어 다수의 기술 스택이 존재하잖아요이때, 이 기술 스택들이 코드로 관리되어야 한다는 요구사항이 존재한다는 예시입니다. 정답은 없는거같지만 이 중 어떤 방법이 최선일지 고민입니다

Clickin · Answer

1, 2 둘 다 검색이 필요없을때만 사용가능합니다.예를 들어서 기술스택을 등록한다고 하면 기업 입장에서는 원하는 기술스택을 가진 사람을 검색할 수 있어야하겠죠그러려면 1,2는 검색에서 성능 저하가 클겁니다.3번이면 조인 검색하면 되겠죠.

tired · Answer

,로 구분해서 넣기도 하고 3번을 쓰기도 하는 편입니다.

난한놈만패 · Answer

3번이 맞습니다테이블 설계시에 정규화 과정을 거치게 되는데 위반사항이 없는지 확인하고 진행하시면 됩니다2번으로 하는 케이스도 있긴한데 대신 조건이 수정 없이 로그성 데이터같은 경우에 하기도 합니다

테스트맨 · Answer

관계형 DB의 설계 관점에서 보면 3번이 가장 올바른 설계방식이라고 생각됩니다.어플리케이션 개발에서 도메인주도개발(DDD) 관점에서 보아도 3번이 가장 올바른 설계방식이라고 생각됩니다.요즘 많이 사용하는 JPA(ORM) 관점에서 보아도 3번이 가장 올바른 설계 방식이라고 생각됩니다.1,2 번을 사용하지 말란 말은 아닙니다.조회성능을 높이거나 특정한 경우에는 역정규화 하는 경우도 있습니다.데이터베이스 설계에 어떤것이 사실 정답이다라는 것은 없지만1,2 번은 검색이나 통계쿼리 작성시 어려움이 있을겁니다.가령 위 예처럼 특정 기술스택을 가진 개발자를 뽑을려면 JOIN이면 끝날 문제를성능 갈가먹는 쿼리로 어찌저찌 하겠죠.아 난 성능이고 모르겠고 빨리 개발해야되고 어짜피 대충쓰고 버릴거야 라면 1,2 번이 가장 좋은 선택이겠죠?다시 말하지만 정답은 없습니다.모든 아키텍처의 정답은 트레이드 오프 관계에서 최선의 방법을 선택하는 겁니다.실제로 DA, AA, TA 아키텍처들의 능력 평가 척도중의 하나도 그 아키텍처가 트레이드오프관계에서 가장 이상적인 것을 잘 선택하느냐 하는 것입니다.

Troublelift · Answer

조금 디테일적인 부분을 말씀드리면ERD는 Entity-Relation-Diagram이라고, 테이블(Entity), 관계(Relation)등을 도식화 해놓은 그림입니다. 설계된 DB가 ERD로 표현이 되는 겁니다. ERD를 설계하진 않고, "DB설계로 ERD를 뽑아내다"가 정확하긴 합니다.

Troublelift · Answer

일단 3번이 맞구요, 회사 - 매칭 테이블 - 기술스택 으로 구현하고, JOIN TABLE을 둡니다. 회사: 기술스택은 Many To Many 관계구요. 검색등에서도 "특정 기술스택으로 검색하기" 혹은 "한 회사의 기술스택 보기" 등의 조회를 가장 효율적으로 . 할 수 있습니다. [조인테이블]회사아이디 기술스택아이디1 21 31 42 22 4이런식으로요~

diegm · Answer

보통은 3번을 많이 사용하고, 저도 3번을 선택했습니다 ㅎ'ㅎ

데이터베이스 설계 단계에서 고민이 있습니다

7개의 답변

기술 목록