數據庫設計存儲通知給用戶

Question

我正在一個文學社區網站上工作。 （screenshot）我試圖找出如何通知用戶，當有人評論他們發佈到網站上的某些內容時，他們正在收看提交的新文獻peice等。

我試圖弄清楚如何構建數據庫來存儲這些信息。我提出了兩個可能的想法。

1. 存儲鏈接到可通知對象，描述用戶被通知的動作類型（新的，更新等）的字段。這使得複雜的顯示代碼，但這意味着我可以改變通知如何工作，而不是容易。這也增加了我需要從數據庫中提取的數據，除非我使用緩存字段將相關屬性的散列轉儲到表中。

   • notifiable_type
   • notifiable_id
   • USER_ID
   • 動作
   • notifiable_cache（可選的，存儲從呈報對象選擇的屬性的散列）

2. 對待，如電子郵件，只是通知用主題和消息將它們保存到數據庫中。這導致了一個簡單的視圖，但一個複雜的模型，並阻止我輕鬆更改通知的工作方式。

   • USER_ID
   • 標題
   • 消息

我正在尋找在兩個我上面列出的其他想法和意見。

Answer 1

我認爲你的第一個選擇是最好的。它比第二個更具可擴展性，它使您能夠輕鬆查找某種類型的每個通知。您將要放棄的數據總量也會更小，因爲您不必將完整的消息保存到用戶。
如果你照顧你如何編寫和設計你的代碼，我認爲它不會太複雜。

但是，如果通知不可能改變，第二個選項可能會更容易實現。

Answer 2

我並不完全確定＃1中「action」字段的用意是什麼，但如果我理解了您的需要，那麼您基本上想讓用戶訂閱通知隊列，對嗎？這些通知是打算通過電子郵件發送給用戶，還是隻在登錄時顯示，或兩者都顯示？

我很想把它想象成一個隊列，在那裏你正在「發佈」通知，並且用戶被「訂閱」了與他們的user_id相關聯的任何通知。在關係模式中，您可能希望使用類似＃1的內容，其中您有一個與用戶關聯的類型的通知。 user_id上的索引當然要確保您可以快速獲取他們的通知。如果您要查詢這些內容，爲了顯示目的而緩存任何內容會非常有意義，這樣您就不必加入任何其他表格 - 這就是假設顯示數據在通知已被「發送」。然而，如果這些通知不需要在用戶在網站上實時更新（例如，如果他們在登錄時顯示或通過電子郵件發送），那麼當他們在他們的網站上查詢時登錄並緩存通知。如果你會實時查詢這些信息以檢查新的通知，並且你有很多用戶，那麼隨着表的增長，這最終會給你帶來麻煩。您可以通過爲不同的通知類型設置不同的表格來分割它，或者除以user_id，但這隻會讓你感到滿意。

您還需要確保您修剪表。您可能需要添加一個標誌來指示用戶已經看到了該通知，但理想情況下，一旦他們看到了該標誌，您可以將其刪除，並且這會使表格變小。

另一種替代方法是將通知保存在rdbms之外。考慮將通知保留在memcached中，例如，如果丟失它們的可能性是可接受的（例如，服務器停機）。或者看看Redis（http://code.google.com/p/redis/），這會使這個問題變得非常簡單 - 存儲通知，併爲每個用戶創建一個集合，並且您幾乎完成了。

只是有些想法，希望它們有用。

Answer 3

message : 
-id_message(pk) 
-to 
-from 
-subject 
-message 
-status (read,unread) 

reply_message : 
-id_reply(pk) 
-id_message 
-from 
-message 
-status (read,unread) 

notification : 
-id_user 
-id_notify(pk) 
-notify_type (message, or reply_message) 
-notify_desc (comment/reply on your message) 
-status (look,unlook) 

notify_detail : (for notify, when user reply or comment more than 1) 
-id_notify 
-id_sender 
-id_detail (input id_message, id_reply) 

這個怎麼樣？您可以將它與評論或回覆評論混合使用。

Answer 4

我最近在一個iOS應用程序的Rails後端做了這個，基本上使用（2）帶有時間戳，但存儲在由用戶索引的Redis列表中。較弱的模式（所有內容都基本填充在'消息'中）讓我們在開發和早期階段更快地移動。

此外，由於通知從Redis列表中彈出，因此就格式更改而言，沒有太多舊信息需要擔心，特別是如果您可以修剪「舊」信息。

Answer 5

我正在利用的通知，以及一個項目，我不知道，如果你有你的整理到現在，或者它可能會幫助，但這樣的表結構我用：

Notifications: 
- ID (PK) 
- recipient_id 
- sender_id 
- activity_type ('comment on a post', 'sent friend request', etc) 
- object_type ('post', 'photo', etc) 
- object_url (to provide a direct link to the object of the notification in HTML) 
- time_sent 
- is_unread