用於向多個用戶發送消息的數據庫模式

我正在尋找實現向系統內多個用戶（Facebook風格）發送消息的最佳解決方案。用於向多個用戶發送消息的數據庫模式

我想出了以下想法：其中每條消息屬於Message_Chain並且在Message_status表中列出了user-sender和users-receivers。但是，如果系統中有數百萬條消息，恐怕這種模式的效率不高。

任何人都可以提出任何其他解決方案到當前的問題？或者解釋爲什麼我的解決方案會很好？

CREATE TABLE `message` (
    `msg_id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT , 
    `msg_text` TEXT NOT NULL , 
    `msg_date` DATETIME NOT NULL , 
    PRIMARY KEY (`msg_id`)); 

CREATE TABLE `message_chain` (
    `msgc_id` INT UNSIGNED NOT NULL AUTO_INCREMENT , 
    `msgc_topic` VARCHAR(255) NULL , 
    PRIMARY KEY (`msgc_id`)); 

CREATE TABLE `message_status` (
    `msgsta_msg_id` BIGINT UNSIGNED NOT NULL , 
    `msgsta_usr_id` INT UNSIGNED NOT NULL , 
    `msgsta_msgc_id` INT UNSIGNED NOT NULL , 
    `msgsta_is_sender` TINYINT(1) NULL , 
    `msgsta_is_read` TINYINT(1) NULL DEFAULT NULL , 
    `msgsta_is_deleted` TINYINT(1) NULL , 
    PRIMARY KEY (`msgsta_msg_id`, `msgsta_usr_id`);

來源

2010-11-23 Websirnik

「不過我怕這個模式是不是很有效時，有數以百萬計的郵件系統中的使用。」 ..我想你應該首先達到這個極限，然後擔心太多的某些細節，過早優化是所有邪惡的根源:) – Jack 2010-11-23 13:59:25

不同意:)成熟的規劃=沒有未來的頭痛 – Websirnik 2010-11-23 14:18:21

只要沒有太多的相同郵件的收件人，架構應該工作得很好。我不明白你如何使它變得更小或更有效。

我能看到的唯一性能問題是，如果您想做廣播，即將相同的消息發送給大型組織，或者說系統上的每個用戶。發送這樣的消息將非常緩慢（在那裏，這樣做）。在這種情況下，我會懶惰地跟蹤這樣的全局消息的狀態，也就是說，只有在打開消息後才能爲單個用戶創建狀態行。但是如果你沒有計劃這樣的功能，我現在就說忽略這個問題。

來源

2010-11-23 14:04:58

我的解決方案是通過使用更多的編程來確定哪些消息傳遞給誰，以避免海量數據存儲。

例如，如果您要發送消息到系統的所有用戶，您將在usr_id列「」，然後programmmatically你可以獲取所有信息，其中usr_id = current_usr_id OR「」。然後，您可以做各種過濾器，並創建自己的語法來創建messager_user列表，而無需數據庫存儲。

好像處理/存儲之間的權衡......

來源

2010-12-11 04:50:13 MikeMurko

用於向多個用戶發送消息的數據庫模式

回答

相關問題