Web消息系統的數據庫結構

我想製作一個像facebook一樣的Web消息系統。我已經想到了很多數據庫結構的替代方案，但不確定哪個是最佳實踐。我在這裏有兩個選擇，第一個使用兩個表格，第二個使用三個表格，但在ERD中創建一個循環。Web消息系統的數據庫結構

第一：兩個表，在該消息表是指本身

user 
---------- 
id 
name 

message 
-------------- 
id 
from_id 
to_id 
message_id --> refer to this table itself, to make me know which message is the topic 
subject 
content 
time 
status --> inbox, outbox, archive 
read --> read, unread

二：三個表，但要一個週期ERD

user 
---------- 
id 
name 

message_header 
-------------- 
id 
from_id 
to_id 
subject 
status --> inbox, outbox, archive 
time 

message 
-------- 
id 
message_header_id 
content 
time 
read --> read, unread 
author_id

就個人而言，我喜歡這樣的結構，因爲它是隻使用一個消息頭和許多消息（內容）。 author_id本身不能被刪除，因爲我需要它來知道消息是在左側（作爲發送者）還是右側（作爲接收者）。這個系統只適用於兩人消息系統。

基本上這兩張表是一樣的，但是這是實現這個消息系統的最佳實踐嗎？謝謝你。

來源

2013-06-27 deka

在學習了艱難的道路（之前，在我最後的項目中......）之後，我會建議你儘可能分離和組織事情。在可能的情況下，自我關係是一件好事，不要靠近（有極少數例外）。一次設計你的課程;然後建立一個數據庫，使事情合適，但應該保持簡單。我的選擇是......不是說好繪製

Diagram

您可能更願意看到的代碼。這是here。
一個可能的查詢從某個標題列表的郵件會

SELECT 
    h.id AS `header_id`, h.`subject`, h.`status`, 
    m.id AS `message_id`, m.content, m.`time`, 
    IF(m.is_from_sender, x.`name`, y.`name`) AS `written_by` 
FROM (SELECT * FROM header WHERE id = @VAR) h 
    INNER JOIN message m ON (h.id = m.header_id) 
    INNER JOIN user x ON (h.from_id = x.id) 
    INNER JOIN user y ON (h.to_id = y.id);

你會看到我的個人偏好對位字段。例如，一旦您的目的是雙人消息傳遞系統，您不必多次記住某個from_id。
我希望你有懷疑。

問候，

萊昂納多

來源

2013-06-27 21:12:39

如果該消息通過答覆的順序來鏈接到某個消息，或者它們應該被列爲每個時間戳 – aeonsleo

使用應答順序（較高IDS第一）可以是小更便宜，但你可能會考慮時間戳順序（當然，有一個合適的索引），比如說，有人在沒有互聯網的情況下應答，並且需要一些時間纔能有效地將消息發送到數據庫。也就是說，你決定：> –

「is_from_sender」屬性有什麼用處？ –

Web消息系統的數據庫結構

回答

相關問題