채팅 서비스 이렇게 ERD 설계하는게 맞을까요!!!?!?!!?

Question

서론 안녕하세요! 현재 채팅 서비스를 만들기 위해 데이터베이스 ERD를 설계를 하였는데요. 설계를 다 하고 보니 너무 관계들이 복잡해 보이고 심지어 못생겨 보이기 시작했습니다. 그래서..! 서버 고수님들께 어떻게 하면 더 직관적이고 깔끔한 ERD를 설계할 수 있는지 여쭈어 보고자 본 글을 계시합니다. 본론제가 만들고자 하는 서비스는 단순 채팅 기능 뿐만 아니라 요구하는 기능이 더 존재하는데요. 다음과 같은 기능들이 존재합니다.친구 추가 기능 채팅방의 알림 on / off 설정 기능 최근 수신한 메시지의 채팅방은 채팅방 목록의 최상단으로 이동 기능(1 : 1 )채팅 기능 1 : N 채팅은 구현하지 않습니다!!먼저 사용자들을 식별하기 위해 저는 User 테이블을 만들었습니다.(질문의 요지만 전달드리고 싶어 필드는 생략하겠습니다.) 그런 뒤 친구추가 기능을 구현하기 위해 Relation(관계) 테이블을 만들었습니다. 그런 뒤 User 테이블과 Relation 테이블의 관계를 N : M으로 해주었습니다.그런데 여기서 Relation 테이블을 유심히 보면 State의 필드를 확인할 수 있을 텐데요. State은 ENUM을 타입으로 가지고 아래와 같은 요소들로 구성됩니다. Accepted &#61; &#34;accepted&#34; // 친구 요청이 수락된 상태 Pending &#61; &#34;pending&#34; // 친구 요청이 대기 중인 상태 Declined &#61; &#34;declined&#34; // 친구 요청이 거절된 상태 Removed &#61; &#34;removed&#34; // 친구 관계가 해제된 상태 이런 구성을 통해 총 4가지의 관계를 표현하게 되고, Accepted State일 경우 본 관계는 이제부터 1 : 1 채팅을 할 수 있는 '채팅방'으로써 간주합니다.그래서 message 테이블을 다음과 같이 표현했습니다. (realtion_id는 채팅방으로써 FK를 가지고, user_id는 누가 전송했는지 식별하기 위해 FK를 가집니다.) 그런 뒤 채팅방의 알림 on / off 설정을 구현하기 위해 room_alter라는 테이블을 만들었습니다. (relation_id는 채팅방으로써 FK를 가지고, user_id는 누가 알림을 on / off 했는지 알기 위한 용도로써 FK를 가지게 됩니다.)이러고 본 테이블도 relation 테이블과 유사하게 state를 통해 상태를 표현하게 되고, state는 allow, deny 의 요소로 통해 상태를 표현합니다. 이제는 최근 수신한 메시지의 채팅방은 채팅방 목록의 최상단으로 이동 기능을 구현하기 위해 last_read_message 테이블을 만들었습니다. 본 테이블은 A사용자가 N번방에서 최근 읽었던 메시지의 ID를 저장합니다. 이것을 통해 현재 message 테이블의 최신 ID랑 대조하여 현재 테이블의 ID가 더 크다면 메시지가 왔다는 것을 인정할 수 있으며 그 결과로 본 채팅방은 채팅방 목록에 최신에 위치시킬 수 있습니다. 그래서 아래와 같은 총 개의 FK를 갖게 되었습니다.결론질문을 작성하다 보니 글이 길어진 감도 있네요... 아무튼 서버 고수님들! 위 erd를 어떻게 하면 좀더 직관성이 높게끔 변경할 수 있을까요? 혹시나 참고가 될 것 같아 ERD 전체 사진을 끝으로 글을 마무리 하겠습니다.

장독깨기 · Accepted Answer

relation 이 친구 요청한 사용자 테이블이죠, 그럼 relation 과 사용자 테이블을 연결해야겠죠.근데, 이 보다는 친구 테이블을 두고 사용자 테이블과 직접 연결하면 될 거 같습니다.이런 식으로요,사용자와 친구 아이디를 복합해서 PK 로 두면 될 것 입니다.그리고, 친구 테이블과 채팅 룸 테이블을 관계 맺으면 될 것이구요,메시지는 이 룸 테이블과 관계를 맺으면 될 것 입니다.그리고, 최근 메시지를 굳이 별도 테이블로 둘 필요 없구요,메시지 테이블 데이터로 정렬을 하거나, 별도로 저장하고 싶으면 룸 테이블에 두면 될 거 같습니다.https://www.erdspace.com ERD 편집 툴 입니다.여기 한 번 이용해보세요. :)

채팅 서비스 이렇게 ERD 설계하는게 맞을까요!!!?!?!!?

1개의 답변

#erd 목록