4

我关心的用户可以是“未确认”或“已确认”。后者意味着他们可以获得完全访问权限，而前者意味着他们正在等待主持人的批准。我不确定如何设计数据库来解释这种结构。

我的一个想法是有 2 个不同的表：confirmedUser 和 unconfirmedUser，它们非常相似，只是 unconfirmedUser 有额外的字段（例如“emailConfirmed”或“confirmationCode”）。这有点不切实际，因为当用户确实被接受时，我必须复制所有信息（尽管我想它不会那么糟糕 - 不期望交通繁忙）。

我想象的第二种方法是将所有用户实际放在同一个表中，并在需要时拥有一个指向带有额外“未确认”数据的表的键（也许还在用户表中添加一个“已确认”标志）。

每种方法的优缺点是什么，是否有更好的方法来设计数据库？

4

4 回答 4

5

第一种方法意味着您需要为两个表编写每个查询 - 为所有常见的。坏（tm）。第二种选择肯定更好。这样，您可以where confirmed = True根据需要添加一个简单的（或 False）特定访问权限。

您实际上可以考虑的是确认的数据（不是用户，只是数据）是否存储在同一个表中。也许将所有确认数据放在一个单独的表中会更清晰+规范化，这样您left join confirmation on confirmation.userid = users.id where users.id is not null （或类似的，或内部联接，或在服务器端脚本中获取所有+过滤器等）以仅获取已确认的用户。确认电子邮件、日期等附加数据可以存储在这里。

于 2012-08-23T16:32:53.203 回答
3

就我个人而言，我会选择您的第二个选项：1 个用户表，其中包含布尔类型的已确认/待定列。将数据从一个表复制到另一个相同的表是不切实际的。

然后，您可以创建组并将特定访问权限附加到每个组，并在需要时将每个用户分配到特定组。

于 2012-08-23T16:37:11.987 回答
3

从逻辑上讲，这是继承（又名类别、子类、子类型、泛化层次结构等）。

从物理上讲，继承可以通过 3 种方式实现，如此处、此处、此处以及可能在 SO 上的许多其他地方所提到的。

在这种特殊情况下，所有类型在同一个表中的策略似乎最合适1，因为层次结构很简单，不太可能获得新的子类，子类只有几个字段不同，您需要维护父级键（即未确认和确认的用户不应该有重叠的键）。

1即您的问题中提到的“第二种方式”。是否也将确认数据放在同一个表中取决于所需的基数 - 即那里是否存在 1:N 关系？

于 2012-08-23T19:02:03.290 回答
1

做到这一点的最佳方法是为用户提供一个表，其中状态 ID 作为外键，状态表将包含所有不同类型的确认以及您可能拥有的所有不同组合。在我看来，这是构建规范化数据库和满足您的编程需求的最佳方式。

所以你的状态表看起来像这样

StatusID | Description
=============================================
1        | confirmed
2        | unconfirmed
3        | CC confirmed
4        | CC unconfirmed
5        | acct confirmed CC unconfirmed
6        | all confirmed

用户表

userID | StatusID
=================
456    |    1
457    |    2
458    |    2
459    |    1

如果您需要确认码，可以将其存储在用户表中。并对其进行编程以在使用后进行更改，以便在他们需要重置密码或其他任何情况时可以使用相同的字段。

也许我假设太多了？

于 2012-08-23T16:31:42.207 回答