在这里，我们有一家假公司，一家血库。核心思想是只有献血者可以献血，但不能登录系统。但是，代表公司的“注册用户”（user表中的行）可以登录系统并查看其公司捐献的血量。捐助者必须与公司有联系。在极端情况下，“注册用户”也可以献血。
- 用户 = 一个“注册用户”。可以登录。
- 捐助者 = 无法登录。
- Admin = 站点管理员。可以登录。
- 血库员工 = 不言自明。可以登录。
未来可能会有其他类型的用户，比如区分“注册用户”的类型。也许，只是也许。
解决方案 1
- 单独的供体表。
优点：
- 寻找捐赠者的查询会更快，尤其是在表格变大的情况下
缺点：
- 如果捐赠者突然想登录怎么办？在表中创建重复条目
user？ - 如果“注册用户”想捐款怎么办？在表中创建重复条目
donor？
解决方案 2
使用 ACL role/user_role表来定义捐助者（和其他用户类型）
优点：
- 易于处理想要稍后以“注册用户”身份登录的捐赠者
- 轻松处理后来想成为捐赠者的“注册用户”
- 也更容易将任何用户提升为管理员
缺点：
- 有些字段是捐助者不需要的，例如“密码”、“节流”，所以 会有额外的 NULL
解决方案 3
与解决方案 2 相同，除了创建一个额外的表user_type。这样做是为了避免重复使用 ACL 系统来控制登录和用户帐户类型的详细信息。
解决方案 4
聚合用户。
这是基于 user1759572 使用聚合用户的建议。我可能没有完全正确地建模它。
你会选择哪个选项？有第四个.. 第五个选项.. 更好的吗？
非常感谢任何答复。这将帮助我确定我几天来一直在反复考虑的最后一点设计。精氨酸。谢谢你！