Web應用程序中的用戶事件訂閱

Question

我們正在開發將具有用戶訂閱特定事件組的Web應用程序。 例如：用戶在blob中創建一條評論，所有訂閱這個博客的用戶應該在他們的列表中包含這個事件。

當前，我們正在搜索數據模型來存儲這些數據。

存儲在一個表中的所有事件，似乎從可用性的角度來看是一個好主意：

• 對象（在本例中：評論參考）
• 可訂閱對象（在本例中：博客引用）
• 用戶生成該事件
• 事件類型（如：更新，創建等）

訂閱事件對於特定用戶而言，可能會被sql查詢收集，該查詢將按用戶訂閱過濾事件。

此數據模型中的問題是可訂閱對象可能具有「繼承」。例如：用戶可能訂閱了博客或博客中的特定帖子。 這意味着博客訂閱會擴展帖子訂閱，並且此數據模型不會反映此行爲。在這種情況下，我將不得不產生2個事件：一個用於博客，另一個用於發佈。

將一個表中的所有事件放在一張表中或者將它們分成不同的表格是一個好主意嗎？無論如何，事件表將會有大量的數據。有沒有更好的主意來組織事件記錄？

Answer 1

一個表中的子類和另一個表中的子類是一個常見問題。

沒有「好主意」的答案。這兩個都是好主意。

一個問題是你將如何查詢它們。

如果你很少做所有不同的事件子類型的聯合，並且你有幾乎沒有重疊的功能，那麼單獨的表就可以很好地工作。

如果你經常做一個聯合風格的查詢，將幾個不同的事件子類型組合在一起，或者你有很多重疊的功能，那麼單個表就可以很好地工作。

另一個問題是多態性。

如果您的所有事件子類型都是正確的多態，那麼您的應用程序（和數據庫）將使用事件子類型的混合集合。這導致你到一個單一的表。

如果您的事件子類型都非常不同，並且不能多態使用，那麼它們應該位於不同的表中。

後果

有了一個表中的所有亞型中，你必須使用空列對於那些不常見的所有亞型屬性。你也應該有一個列，告訴哪一行代表的子類型。

將多個子類型放在一個表中時，您必須有一個區分列來判斷該行應該是哪個子類型。

將子類型放在單獨的表中時，您有兩種設計。

• 在所有表中重複公共元素。在沒有共同點的時候這樣做。

• 讓子類型表連接到超類型表，並將常用元素放在一個表中。在幾乎所有事情都很常見的時候這樣做