选择哪种数据库结构？

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。