목적

사용자와 상점과의 채팅 앱을 실현하는 DB 설계를 실시합니다.

일대일 메시지 앱이 아니라 다음과 같은 1대 N 특징이 있는 채팅 앱을 생각하고 싶습니다.



사용자는 상품을 통한 매장마다 메시지를 교환할 수 있으며, 매장은 상품별로 헤어진 채팅으로 사용자와 교환할 수 있습니다.
여기서는 모두 RDS상에서 완결하는 구성으로 생각합니다.

ER 다이어그램 만들기

등장인물을 생각한다

유저와 점포와의 채팅 앱을 생각하는데 있어서, 최소한, 필요한 등장 인물은 이하가 될 것 같습니다.

상점

사용자

매장

여기에 이름, 아이콘이 있습니다.
▼shops(점포 테이블)

사용자

마찬가지로 이름, 아이콘을 갖습니다.
▼users(사용자 테이블)

다른 필요한 Entity를 생각

채팅 앱이라면 메시지와 토크룸도 필요할 것 같습니다.
그리고 이번에는 "상품마다 설명을들을 수있는 방"이 있기 때문에 상품도 필요합니다.

상품

메시지

토크 룸

상품

상품명, 이미지, 점포 ID가 있으면 좋을 것 같습니다.
▼items(상품 테이블)

메시지

채팅을 통해 상호 작용하는 메시지입니다.
"누가 누구에게 보냈는지""어떤 방에서 어떤 상품에 대한 교환인가"가 필요하기 때문에 다음과 같은 컬럼이 필요할 것 같습니다.

사용자 ID, 상품 ID, 상점 ID. 방 ID, 메시지 본문, 보낸 사람, 대상

여기서 송신원/송신처에 주목하면, 이번은 점포와 유저의 채팅 어플리케이션이므로, 유저끼리·점포끼리의 채팅은 불필요합니다.
굳이 컬럼을 2개로 하는 이유도 없기 때문에, 송신원/송신처는 번호(1:유저, 2:점포)로 갖게 합니다.

▼messages(메시지 테이블)

방

객실 이름, 상품 ID, 사용자 ID가 필요하지만,
「점포는, 개별의 상품마다 유저와 교환」을 실시할 필요가 있기 때문에, 「유저가 이용하는 방」과, 「점포가 이용하는 방」으로 다른 Entity를 작성하고 싶습니다.

또, 여기에서는 LINE과 같이 메세지 마다의 상태를 가지게 해, 기독/미독/회신 완료 상태를 가지는 것으로 생각합니다.
스테이터스는 메세지마다 존재하기 때문에, 언뜻 보면 메세지에 갖게 하려고 생각했습니다만, 실운용으로서 토크룸 마다의 최신 메세지에 상태가 있으면 좋기 때문에, 채팅 룸마다 갖게 하는 설계로 했습니다.

▼rooms(사용자 시점의 대화방 테이블)


▼shop_room(점포 시점의 채팅 룸 테이블)

ER 다이어그램

마지막으로, 이들을 정리하면 다음과 같은 설계가 됩니다.


이상, 1대 N의 특징이 있는 채팅 앱에서의 DB 설계에 대해서였습니다.

유스 케이스로서 유저와 점포에서의 이용 방법은 어떻게 될까를 생각하면서 작성했기 때문에, 이러한 쪽이 좋은 등 있으면 꼭 코멘트 받을 수 있으면 기쁩니다.
원래, 메시지 자체 RDS에 보존시키는 것은 부하가 된다는 점도 우려하기 때문에, 맞추어 지적 받을 수 있으면 다행입니다.