新聞提要數據庫設計效率

問候所有，我看到過類似的問題，但沒有確定的答案或測試的答案。新聞提要數據庫設計效率

我正在設計一個使用類似Facebook的PHP/MySQL的新聞饋送系統。看到這張表格可能變得相當大 - 任何效率低下都可能導致嚴重的瓶頸。

實例聲明：（以粗體鏈接的對象項目）

USER_A和USER_B評論User_C的新專輯。

User_A添加了一個新的車輛到[他/她]車庫。

最初，我使用Obj1的過多列實現了這個：Type1 | Obj2：Type2 |

它的工作原理，但我擔心它不夠可擴展，現在我正在尋找對象序列化。

因此，例如我的新數據庫建立像這樣：

News_ID | User_ID |     News_Desc   | Timestamp 

    2643   904  {User904} and {User890} commented on  SomeTimestamp 
         {User222}'s new {Album724}.

任何內部{'s表示，將使用JSON序列化的數據。

這是一種智能（高效/可擴展）的前進方式嗎？

使用正則表達式難以將序列化數據與字符串的其餘部分分開嗎？

來源

2010-01-11 pws5068

如果User890刪除了他/她的評論，會發生什麼情況？我認爲你需要更加原子化 - 可能將動作類型（評論）與動作者（User890）存儲在一起，然後通過沉重的緩存動態生成實際的故事。如果您將網站擴展到多個市場/受衆羣體，這也有助於翻譯問題。

來源

2010-01-11 23:23:41

非常好的一點。這意味着我還應該存儲action元素的ID和TypeID，例如，我可以從「delete_comment（）」函數中移除供稿條目。我從來沒有考慮過翻譯，緩存將保持我的數據庫大小最小。 – pws5068 2010-01-11 23:32:00

我認爲反規範化在這裏會更有效率。評論是否被刪除真的很重要嗎？如果它只是一個新聞提要，那麼它只是真正的靜態數據，我假設。 – Louis 2010-01-12 00:19:29

新聞提要數據庫設計效率

回答

相關問題