用戶通知系統的架構

我正在爲需要在管理員登錄時能夠接收通知的用戶編寫Web應用程序。這些通知應顯示在其儀表板上。用戶通知系統的架構

一旦用戶閱讀了消息，他們可以解僱它。顯然，新用戶在創建之前不應顯示消息。

我有兩個問題，設計模式：

如何識別用戶已「開除」的消息？
新用戶在創建後只能看到消息嗎？

這裏的表通知：

CREATE TABLE [dbo].[Notification] 
(
    [Id] [int] IDENTITY(1,1) NOT NULL, 
    [Message] [varchar](max) NOT NULL, 
    [DateCreated] [datetime] NOT NULL, 
    [CreatedById] [int] NOT NULL 
)

＃1，我想創建一個表（DismissedNotification_User），將一個Notification.Id和User.Id之間進行映射的。如果存在一對，則用戶駁回該通知。但是，我不確定這是否是最好的方法（not in vs left join）？

對於＃2，我看到的最簡單方法是向用戶添加DateCreated列，並在＃1（where [DateCreated] >= [User].DateCreated）上添加條件。

我不想要cookies，因爲這確實會給應用程序增加不必要的重量。

來源

2012-03-05 TheCloudlessSky

我會說你自己的解決方案＃1和＃2在這裏看起來很好。

表示「解僱」通知的鏈接表是有意義的，否則最終不得不爲每個用戶在前面創建一行，以表示通知而不是一個通知記錄。

我認爲＃2，有一個通知的創建日期和用戶將是一個明智的選擇。如果您依賴於鏈接表的選項，則使用'已解僱'列的其他建議不會使您僅在創建用戶後顯示通知，因爲您最終將收到所有通知，而不僅僅是因爲用戶存在。

來源

2012-03-05 14:26:55 dougajmcdonald

謝謝 - 我將堅持我原來的計劃。 – TheCloudlessSky 2012-03-06 13:17:12

我認爲這是最明智的選擇，我最近做了類似警報系統的工作。我打算爲每個用戶插入一行並刪除它們，但由於我們有2-3,000個用戶，並且警報一次只能與10-20個用戶相關，因此添加數千行永遠不會觸及的行似乎效率低下。 – dougajmcdonald 2012-03-06 14:47:43

＃1：添加一個新列Notification表像dismissed或數據類型bit即boolean的readed用默認值0或假，然後在你的應用程序，一旦用戶打開該郵件，將dismissed的值更新爲1，我看到其他系統添加了一個名爲Mark的按鈕，以確保用戶閱讀它。
＃2：您可以使用此字段dismissed，只顯示那些已經因爲他們還沒有被opended和用戶readed尚未駁回，用戶的消息。

所以通知表看起來是這樣的：

[Notification] 
(
    [Id] [int] IDENTITY(1,1) NOT NULL, 
    [Message] [varchar](max) NOT NULL, 
    [DateCreated] [datetime] NOT NULL, 
    [CreatedById] [int] NOT NULL, 
    [Readed] bit Default(0) 
)

您將需要一個額外的表來存儲通知每個用戶的喜歡，

dbo.UserNotifications 
(
    UserId, NotificationId 
)

在您的應用程序時，用戶登錄到系統檢查通知readed = 0。

來源

2012-03-05 14:18:55

您可以通過創建一個包含用戶和消息的表來加入這兩個任務。當管理員發送消息時，您爲每個現有（活動？）用戶創建條目。如果您不需要歷史記錄，則可以在用戶解除通知後刪除消息;否則你應該添加'Dismissed'列。這樣您就不需要複雜的查詢來獲取需要呈現給用戶的通知。

來源

2012-03-05 14:19:39

用戶通知系統的架構

回答

相關問題