Question

我正在开发我的第一个真正的Rails应用程序，用于公司的时间跟踪，我遇到了数据库/模型设计问题。我的应用程序有一个用户模型和一个角色模型，它们通过has_and_belongs_to_many关联链接在一起。

其中一个角色是经理。经理可以有很多助理，助理可以有很多经理（虽然通常只有一个）。此关系通过在User模型中表示为：

的manager_assistant_relationship表示

has_many :assistants, :through => :manager_assistant_relationships
has_many :managers, :through => :manager_assistant_relationships

助理可以有很多班次（代表工作班次的不同模型），经理可以有很多客户（另一种模式将为助理的工作付费）。更多的协会即将到来。

据我所知，唯一的解决方案是将所有这些关系放在用户模型中，但是对此有些不对劲，随着角色的增加和关联的增加，用户模型会变得臃肿，而且看起来也不直观，因为如果他是经理，用户只有很多助手。我想就这种方法的潜在缺陷以及我应该考虑的替代方案提出一些建议。

将User模型子类化为角色是不是一个好主意？

Answer 1

好消息，你正确地扮演角色。

要回答您的问题，否将User模型子类化为您所描述的内容并不是一个好主意。如果你这样做，它往往导致关联，STI（单表继承），或继承或类而不是模块组合的棘手的自连接。使用角色要好得多。

它可能会帮助您将用户视为一个人，而不是一个角色。因此，User类仅包含个人信息，例如姓名，出生日期，身高，可能还有电子邮件地址，登录密码等。将个人信息与时间跟踪角色分开。

要使用您的角色，您可以执行类似此伪装的模型关系：

 class Manager
   has_many :clients
 end

 manager = Manager.find(id)
 client = manager.clients.first

或者喜欢这个伪代码：

 class Assistant
   has_many :workshifts
 end

 assistant = Assistant.find(id)
 workshift = assistant.workshifts

如果您想了解这些角色，可以选择使用Role-Based Access Control (RBAC)和Data Context Interation (DCI)的其他正当理由。