選擇哪種數據庫結構？

Question

我想實現一個通知系統。我有用戶和每個用戶都有通知設置

結構1：

Users    Notification_settings    Notifications 
-id (pk)    -id         -id (pk) 
-username   -user_id (fk) references Users  -user_id (fk) 
-password   -receive_email (boolean)    -message 
                  -is_read 

結構2：

Users            Notifications_settings 
-id (pk)            -id (pk) 
-setting_id (fk) references Notifications_settings -receive_email 
-username            
-password    

Notifications 
-id (pk) 
-user_id (fk) 
-message 
-is_read 

的數據庫結構來選擇或通知系統任何其他數據庫的結構？

Answer 1

如果你的網站流量不是很大，你把它放在同一張表（用戶和設置）中。這是OP的相關答案。
通常，U分離1:1到不同的表中，當幾個條件發生（一起）：

1. 各組字段是有關在應用程式不同的模塊
2. 各組字段是存取在不同速率（用戶名/密碼，每次登錄，計費設置在每週一次/兩次，例如）
3. 有巨大的流量到您的網站，其中u需要從您的系統

牛奶的任何性能ounch你可以從阿博看到大多數人不需要將它分開。

Answer 2

它似乎應該是用戶<通知（一對多），但也許你有一個特定的原因，它應該是1-1。在這種情況下，我會使父表（沒有FK列的表）具有更多的一對多關係。所以，自然地，在通知表中使用用戶ID存儲是有意義的。

這似乎是一個通知總是有一個用戶，但反之亦然。因此，您應該將外鍵存儲到通知表中的用戶標識 - 而不是相反。

edit--正如其他人所建議的那樣，如果您確實需要1-1關係，則可以將通知字段添加到用戶表中。這些似乎一目瞭然違反規範化規則，但如果reeeaaaally是一個1-1的關係，然後通過各種手段，有它

編輯2 - 既然你明確表示，通知不無存在用戶，我會明確地說，你應該外鍵存儲在通知表用戶，沒有例外（如果你要存儲用戶的表:)

編輯＃2937內部通知信息，除非：

您應該將用戶的通知首選項存儲在第e 用戶表 - 除非您有一些令人迷惑的設計，並且已經爲您的用戶提供了256列，並且這是限制，否則無需將其拆分到不同的表中。

您應該將通知存儲在單獨的表中，並提供從用戶到通知的一對多關係。這是我最後的answe，吉斯:)

Answer 3

現在的Joe Celko quote：

一個強大的實體是一個對自己的優點存在。一個弱實體是由於一個強大的實體而存在的實體。典型的例子是銷售訂單的例子;訂單標題很強，訂單細節較弱。如果訂單被刪除，那麼所有的訂單細節應該消失。

那麼，那麼，用戶是否可以自己存在沒有通知？然後，通知表應該有用戶的外鍵。反過來是真的嗎？然後換個方式。這些都不是真的嗎？那麼也許你的模型是不正確的，它們之間應該有一個junction table（即使有唯一的約束），或者他們確實屬於同一個表。我不特別喜歡把它們放在同一個表格中的最後一個選項，因爲你已經自然想出了兩個名詞來描述不同的實體。

用戶以外的其他實體「是否有」通知？也許這種想法可以幫助你對這個領域進行建模。

更新 - 一些額外的想法：

如果你把所有這些列到一個表，這其中，如果有的話，現在看起來它會包含冗餘數據？假設現在只有幾條不同的信息。也許你不需要通知表，而是需要一個消息表，以及該表與用戶之間的交接表，它可以存儲發送給用戶的消息，包括是否已經閱讀。在這一點上，receive_email可能是用戶的一個更好的屬性，儘管可能只是將消息映射到用戶就足以說該用戶應該接收電子郵件。這些只是我可能想到的一些事情，並希望能夠更好地理解應用程序。

另外，要注意bit/boolean數據類型不是ANSI SQL，通常可以從其他數據中派生出來，或者甚至可以在路徑映射到多個狀態時變成int。