通知/供稿/請求的基本模式設計？

我正在設計一個社交網絡，並想知道我是否在正確的軌道上。我在網站上有Notifications，Requests和Live Feed。類似於我們目前在大多數網站上看到的情況。爲了設計這些，我假設這些不是單獨的組件，而是它們全部從相同的Activity組件流出來？通知/供稿/請求的基本模式設計？

系統有一組說200活動可能涉及30個對象。 40項活動可能有通知，70項可能有供稿，10項可能有請求。因此，我認爲這些將成爲活動查找表的一部分 - 活動是否具有Feed，Notification和Request作爲布爾列。如果是，則默認文本顯示給所有3（Feed，Notification，Request）給用戶，如「NAME評論照片」。另一列將FK添加到對象查找表中，以將對象與活動進行匹配。

所以基本上我不確定這些應該全部是活動查找表的一部分還是有其他一些設計要考慮？

一個可能的用例就像通知 - 系統可能有40個可用，但用戶只能選擇其中的10個。所以會有一個單獨的用戶設置表來保存用戶定義的首選項。

來源

2010-11-01 tony23

一個比較模糊的問題，在「社交網絡」/「數據庫」/「設計」中有這麼多相關的問題...... – pascal 2011-01-28 06:28:38

基於您的設計和規則的簡單性，跳過DBMS。這太過分了（我是經典DBMS的忠實粉絲）。現在學習卡桑德拉。通知可以快速添加和刪除，並且可以很好地擴展。否則，我認爲這裏沒有足夠的信息來真正澄清你正在嘗試做什麼，但我正在冒出一個猜測。 – Horus 2011-04-18 14:29:38

@Horus：我不同意。你不應該因爲它們太簡單而使事情變得更復雜。一個簡單的數據庫層允許他專注於更重要的問題，如創新功能。 – 2011-11-30 18:28:01

你在做什麼聽起來對我來說很理智。在這種情況下，活動關係似乎可用。大問題圍繞着規模，但這些可以通過db解決方案解決（例如Postgres上的Postgres-XC）。

我沒有看到一個明顯的方法來改善那裏的關係設計。

來源

2012-09-05 10:26:00

通知/供稿/請求的基本模式設計？

回答

相關問題