我关注的用户可以是“未经证实”或“已确认”。后者意味着他们获得完全访问权限，前者意味着他们在主持人批准后待审。我不确定如何设计数据库来解释这种结构。
我想到的是有两个不同的表：confirmedUser和unconfirmedUser非常相似，只是unconfirmedUser有额外的字段（例如“emailConfirmed”或“confirmationCode”）。这有点不切实际，因为当用户被接受时我必须复制所有信息（虽然我认为它不会那么糟糕 - 不要期待大量流量）。
我想象的第二种方法是实际将所有用户放在同一个表中，如果需要，可以使用额外的“未经证实的”数据来获取表的密钥（也许还会在用户中添加“已确认”标志表）。
每种方法的缺点有哪些优点，是否有更好的方法来设计数据库？
答案 0 :(得分：5)
第一种方法意味着你需要为两个表编写每个查询 - 用于所有常见的事情。坏（tm）。第二种选择肯定更好。这样，您可以根据特定访问权限添加简单的where confirmed = True（或False）。
您实际可以思考的是，确认的数据（不是用户，只是数据）是否存储在同一个表中。将所有确认数据放在一个单独的表中可能会更清晰+规范化，以便left join confirmation on confirmation.userid = users.id where users.id is not null （或类似，或内部联接，或者在服务器端脚本中获取所有+过滤器等）只获得确认的用户。确认电子邮件，日期等附加数据可以存储在此处。
答案 1 :(得分：3)
就个人而言，我会选择第二个选项：1个用户表，其中包含boolean类型的已确认/待定列。将数据从一个表复制到另一个表是不切实际的。
然后，您可以创建组并为每个组附加特定的访问权限，并在需要时将每个用户分配到特定的组。
答案 2 :(得分：3)
逻辑上，这是继承（也就是类别，子类，子类型，泛化层次等）。
从物理上讲，继承可以通过3种方式实现，如here，here，here以及可能在SO上的许多其他地方。
在这种特殊情况下，同一个表中所有类型的策略似乎最合适 1 ，因为层次结构很简单，不太可能获得新的子类，子类只有少数几个字段而你需要维护父级别的密钥（即未经证实和确认的用户不应该有重叠的密钥）。
1 I.e。你问题中提到的“第二种方式”。是否也将确认数据放在同一个表中取决于所需的基数 - 即那里是否存在1：N关系？
答案 3 :(得分：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
如果您需要确认码，可以将其存储在用户表中。并在使用后对其进行编程以便更改，以便在需要重置密码时可以使用相同的字段。
也许我假设太多了？