2017-09-29 26 views
0

我正試圖設計數據庫模式,使其能夠同時進行私人聊天和羣聊。下面是我到目前爲止有:用於聊天的數據庫模式:私人和組

enter image description here

所以 - 的理論是,即使用戶只是在一對一私聊,他們仍然被分配一個「roomID」,和每個消息他們發送的是room
要了解他們所涉及的所有房間,我可以從表participants中選擇一個列表以查找。

這是正常的,但是感覺對我來說,room表是略顯多餘,因爲我並不真的需要一個房間名稱,我可以離開它,只需使用participants表和SELECT DISTINCT roomID FROM particpants找出個別房間。

任何人都可以向我解釋一個更好的結構或爲什麼我應該保持房間的桌子?

+0

你有外鍵嗎? –

+0

@RyanGadsdon是的行代表外鍵 – Chud37

+0

啊我看到了,以前看到FK旁邊的名稱:)我會分開私人和公共房間。或者使用私人和公共房間子類創建房間屬性。我會保留空間,因爲如果你有不同的聊天室會發生什麼?如體育,社交,工作。將人們鏈接到聊天室會更容易 –

回答

0

我認爲您可能需要稍微改進您的域模型 - 如果沒有這一點,很難說您的模式是否「正確」。

以鬆弛爲模型(注意 - 我沒有做過大量的研究,所以細節可能是錯的),你可能會說你的系統有「聊天」。

聊天可以是公開的 - 即列出所有用戶可以看到和加入 - 或者私人 - 即沒有爲所有用戶列出,並且只有通過邀請可用。

公共聊天記錄必須具有「名稱」屬性。私人聊天可能會或可能不會有名稱屬性。

聊天可以有2..n個參與者。

默認情況下,所有1-1聊天開始爲私人聊天。

可以將私人聊天改爲公共聊天。

在這種情況下,你有繼承/專業化關係 - 「私人」和「公共」是「聊天」的子類型。

關係模型在處理繼承問題上出了名; SO上有很多relatedquestions

0

我會做更像這樣的一個簡單的聊天系統與組和私人聊天(兩名成員)。

erm

A以外posibility是隻爲組消息,一個用於普里瓦聊天創建表。 (避免組與消息表之間的n:m,或者使用n:m作爲特徵,而不是作爲可能的錯誤/邏輯錯誤)。如果你想要一個更復雜的聊天系統看看Neville Kuyt的帖子。

我希望我能夠幫助你。