我们这里有一家假公司，一家血库 . 核心思想是，只有捐赠者可以捐献血液但不能登录系统 . 但是，代表公司的"registered user"（ user 表中的行）可以登录系统并查看其公司捐赠的血量 . 捐助者必须与公司联系 . 在边缘情况下，"registered user"也可以献血 .
User = A "registered user". Can log in.
Donor = Cannot log in.
Admin = A site administrators. Can log in.
Blood bank employee = Self explanatory. Can log in.
将来可能会有其他类型的用户，例如区分“注册用户”类型 . 也许吧，也许吧 .
解决方案1
Separate donor table.
PROS:
• Queries to find donors will be faster, especially if the table grows large
CONS:
• What to do if a donor suddenly wants to log in? Create a duplicate entry in the `user` table?
• What if a "registered user" wants to donate? Create a duplicate entry in the `donor` table?
解决方案2
Use ACL `role`/`user_role` tables to define donors (and other user types)
PROS:
• Easy to handle a donor that wants to later login as a "registered user"
• Easy to handle a "registered user" that later wants to become a donor
• Also easier to promote any user to an admin
CONS:
• There are fields that donors do not need, like 'password', 'throttled', so
**There will be extra NULLs**
解决方案3
Identical to Solution 2, except creating an additional table `user_type`. This would be done to avoid re-using the ACL system for controlling log in & user account type details.
解决方案4
Aggregate user.
这是基于user1759572建议使用聚合用户 . 我可能没有完全正确地建模 .
你会选择哪个选项？有没有第4 ...第五选项...更好的东西？
Any reply is very much appreciated . 这将帮助我确定最后一点设计，我已经在这几天蹦蹦跳跳了 . 精氨酸 . 谢谢你！
1 回答
使用Party Model和Party Role模型 . 个人或组织（如公司）继承自抽象的法律方 . 一方可以扮演很多角色，比如捐助者，工作人员 .
我将使用支持真实用户和组的数据库，以及可更新的视图，WITH CHECK OPTION，而不是滚动您自己的用户和组登录 .