我关注的用户可以是“未确认”或“已确认”。后者意味着他们获得完全访问权限，而前者意味着他们正在等待主持人的批准。我不确定如何设计数据库来解释这种结构。
我的一个想法是拥有两个不同的表：confirmedUser 和 unconfirmedUser，它们非常相似，只是 unconfirmedUser 有额外的字段（例如“emailConfirmed”或“confirmationCode”）。这有点不切实际，因为当用户被接受时，我必须复制所有信息（尽管我认为情况不会那么糟糕 - 预计不会有大量流量）。
我想象的第二种方法是将所有用户实际放在同一个表中，并在需要时拥有一个带有额外“未确认”数据的表的密钥（也许还可以在用户表中添加一个“已确认”标志）。
每种方法的优点和缺点是什么？是否有更好的方法来设计数据库？
第一种方法意味着您需要为两个表编写每个查询 - 对于所有常见的内容。坏（tm）。第二种选择肯定更好。这样你就可以添加一个简单的where confirmed = True（或 False）根据特定访问的需要。
你真正可以思考的是确认的数据（不是用户，只是数据）是否存储在同一个表中。也许将所有确认数据放在一个单独的表中会更干净+规范化，这样您就可以left join confirmation on confirmation.userid = users.id where users.id is not null （或类似，或内部联接，或在服务器端脚本中获取所有+过滤器等）仅获取已确认的用户。确认电子邮件、日期等附加数据可以存储在此处。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
