240227 TIL | ERD 설계 고민

왕초보일지

다시은 2024. 2. 29. 19:35

오늘 한 일

ERD 를 수정하다가 든 생각

그동안 연관관계를 생성할 때 별 고민없이 식별관계로 설정해놓았는데

식별관계와 비식별관계의 차이점을 정확하게 구분하고 가야지 ERD 설계를 제대로 하는 것 아닌가 하는 생각이 들었다.

ERD Cloud 를 기반으로

식별관계는 파란색 키, 비식별관계는 분홍색 키로 나타난다.

식별관계

: 부모 테이블의 기본키/유니크 키를 자식 테이블이 자신의 기본키로 사용

: 반드시 부모 테이블에 데이터가 존재해야 자식 테이블에 데이터를 입력할 수 있다

: 부모 데이터가 없다면 자식 데이터는 생길 수 없다.

: 요구 사항이 변하지 않을 때 강력한 정합성 보장

비식별관계

: 부모 테이블의 기본키 또는 유니크 키를 외래 키로 사용하는 관계

: 자식 데이터는 부모 데이터가 없어도 독립적으로 생성될 수 있다.

: 부모 데이터와의 의존성 제거

보통은 비즈니스 로직이 변경될 일이 잦지 않다면 식별관계를, 자주 변경된다면 비식별관계를 이용한다고 한다. 환경에 따라서 적절한 관계를 설정해야 한다.

그동안 연결만 하면 끝 아닌가 하는 안일한 생각으로 설계해왔었는데 많은 고민을 해보고 적용해야 할 것 같다.

채팅 설계의 경우

다대다 채팅으로 채팅방이 생성되면

참여하는 회원리스트를 볼 수 있는 채팅 참여 row 가 생성되고

채팅방의 이름, 상태 정보를 가지고 있는 채팅방 row가 생성되고

메시지를 주고받으면 채팅방 아이디와 보낸회원 아이디를 가지고 있는 메시지 row 가 생성된다.

메시지의 경우 모임 아이디를 알 필요까진 없다. 해당 모임에서 하나의 채팅방만 생성할 수 있으니 채팅방 아이디를 가져오면 된다.

채팅참여목록은 회원id 와 채팅방 id 를 기반으로 생성되므로 식별관계로 설정해놓았다.

스케일아웃

샌드버드 채팅 솔루션

redis

참조

ERD 변경사항