개인 채팅과 그룹 채팅을 모두 사용할 수있는 데이터베이스 스키마를 설계하려고합니다. 여기에 지금까지있어 무엇 : 그래서채팅을위한 데이터베이스 스키마 : 비공개 및 그룹
- 이론은 사용자가 하나 하나에 개인 채팅에 불과하더라도, 그들은 여전히 'roomID', 및 각 메시지를 할당한다는 것입니다 그들은 room에 보낸다.
그들이 관련된 모든 객실을 찾으려면 테이블 에서 목록을 선택하여 확인할 수 있습니다.
이 괜찮는, 그러나 그것은 room 테이블이 정말 방 이름이 필요 없다는 점에서 약간 중복 저에게 느낌, 나는 알아 SELECT DISTINCT roomID FROM particpants 그것을 생략하고 단순히 participants 테이블을 사용할 수 있습니다 각 방.
누구나 나에게 더 나은 구조를 설명 할 수 있습니까? 왜 내가 방 테이블을 유지해야합니까?
도메인 모델을 좀 더 세밀하게 조정해야 할 필요가 있다고 생각합니다. 스키마가 "옳은"것인지 여부는 말하기 어렵습니다.
슬랙을 모델로 삼아서 (참고 - 이것에 대한 많은 연구를하지 않았기 때문에 세부 사항이 잘못되었을 수 있습니다), 시스템에 "채팅"이 있다고 말할 수 있습니다.
채팅은 모든 사용자가 보거나 가입 할 수 있도록 공개되거나 비공개 (즉, 모든 사용자에 대해 나열되지 않고 초대로만 이용 가능) 할 수 있습니다.
공개 채팅에는 "이름"속성이 있어야합니다. 비공개 채팅에는 이름 속성이있을 수도 있고 없을 수도 있습니다.
채팅에 2..n 명이있을 수 있습니다.
모든 1-1 채팅은 기본적으로 비공개로 시작됩니다.
개인 채팅을 공개 채팅으로 변경할 수 있습니다.
이 경우 상속/전문화 관계가 있습니다. "private"및 "public"은 "chat"의 하위 유형입니다.
그룹 및 privat 채팅 (2 명)과 간단한 채팅 시스템을 사용하면 더 좋아집니다.
다른있는 posibility는 그룹 메시지 및 privat의 채팅 하나의 테이블을 만드는 것입니다. (그룹과 메시지 테이블 사이의 n : m을 피하기 위해 또는 n : m을 가능한 버그/로직 오류가 아닌 기능처럼 사용하십시오). 좀 더 복잡한 채팅 시스템을 원한다면 Neville Kuyt 게시물을보십시오.
내가 당신을 도울 수 있기를 바랍니다.
외래 키가 있습니까? –
@RyanGadsdon 예 라인이 외래 키를 가리키고 있습니다 – Chud37
아하 저는 이름 옆에있는 FK를 보는 데 익숙합니다. 저는 개인 방과 공공 실을 분리 할 것입니다. 또는 private 및 public room 하위 클래스로 Room 속성을 만듭니다. 다른 대화방이 있다면 어떻게 될까요? 예 : 스포츠, 사회, 직장. 사람들을 대화방에 연결하는 것이 더 쉬울 것입니다. –