3

我想实现一个通知系统。我有用户，每个用户都有通知设置

结构一：

 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

结构二：

 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

通知系统选择哪种数据库结构或任何其他数据库结构？

4

3 回答 3

2

现在引用 Joe Celko 的话：

一个强大的实体是一个依靠自己的优点而存在的实体。弱实体是因为强实体而存在的实体。典型的例子是销售订单。订单标题很强大，订单细节很弱。如果订单被删除，那么所有订单详细信息都应该消失。

那么，用户可以在没有通知的情况下独立存在吗？然后通知表应该有用户的外键。反过来是真的吗？然后换一种方式。这些都不是真的吗？那么也许你的模型不正确，它们之间应该有一个联结表（即使上面有唯一的约束），或者它们确实属于同一个表。我不特别喜欢将它们放在同一张表中的最后一个选项，因为您已经自然地想出了两个名词来描述不同的实体。

用户以外的其他实体可以“拥有”通知吗？也许这种想法可以帮助你为这个领域建模。

更新- 一些额外的想法：

如果您要将所有这些列放入一个表中，其中哪一个（如果有）现在看起来将包含冗余数据？让我们想象现在只有几个不同的消息。也许您不需要 Notifications 表而是 Messages 表，以及该表和用户之间的联结表，该表可以存储随时间发送给用户的消息，包括它们是否已被阅读。在这一点上，receive_email 可能是用户的一个更好的属性，尽管可能仅将消息映射到用户就足以说明该用户应该接收电子邮件。这些只是我可能正在考虑的一些事情，并希望能够更好地理解该应用程序。

此外，请注意位/布尔数据类型不是 ANSI SQL，通常可以从其他数据派生，或者甚至可以转换为映射到多个状态的 int。

于 2013-02-05T02:18:10.483 回答
2

似乎应该是用户<通知（一对多），但也许你有一个特定的原因应该是1-1。在这种情况下，我会让父表（没有 FK 列的表）成为具有更多一对多关系的表。因此，很自然地，将用户 ID 存储在通知表中是有意义的。

通知似乎总是有一个用户，但反之则不然。因此，您应该将外键存储到通知表中的 UserID 中——而不是相反。

编辑——正如其他人所建议的，如果您确实想要 1-1 关系，您可以将通知字段添加到 User 表中。乍一看这些似乎违反了规范化规则，但如果它确实是 1-1 关系，那么无论如何，有它

编辑 2- 由于您明确声明没有用户的通知不存在，我会明确地说您应该将外键存储到通知表中的用户，没有例外（除非您想将通知信息存储在用户的桌子 ：）

编辑＃2937：

您应该将用户的通知首选项存储在User表中 - 无需将其拆分为不同的表，除非您有一些混淆设计并且已经为您的用户提供了 256 列，这就是限制。

您应该将通知存储在单独的表中，并具有从用户到通知的一对多关系。这是我最后的答案，瑞吉斯 :)

于 2013-02-05T02:15:06.550 回答
0

如果您的网站流量不大，请将其全部放在同一张表中（用户和设置）。 这是 OP 的相关答案。
通常，当几种情况（一起）发生时，您将 1:1 分成不同的表：

  1. 每组字段都与您应用中的不同模块相关
  2. 每组字段以不同的速率访问（例如，每次登录的用户名/密码、每周一次/两次的计费设置）
  3. 您的网站有大量流量，您需要从系统中榨取任何性能

正如您从上面看到的，大多数不需要将其分开。

于 2013-02-05T02:12:44.357 回答