240227 TIL | ERD 설계 고민

오늘 한 일

1. gitgub repository 생성, 템플릿 추가
2. ERD 수정

 

 

ERD 를 수정하다가 든 생각

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

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

 

ERD Cloud 를 기반으로 

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

 

식별관계

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

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

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

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

 

비식별관계

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

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

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

 

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

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

 

 

 

 

 

채팅 설계의 경우

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

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

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

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

 

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

 

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

 

 

스케일아웃 

샌드버드 채팅 솔루션

redis

 

 

 

참조

https://inpa.tistory.com/entry/DB-%F0%9F%93%9A-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EB%A7%81-1N-%EA%B4%80%EA%B3%84-%F0%9F%93%88-ERD-%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8

 

 

 

 

 

ERD 변경사항

• 랭킹시스템
• 채팅
• 본인인증