我必须在我的应用程序中实现一个授权角色系统。我们的系统中有大约5种角色。枚举vs单独的表来存储角色？
为了维持这些角色，我们有2种选择，
替代＃1
1，创建在轨榜样枚举，
enum role: {super_admin: 1, translator: 2, approver: 3, sales_admin: 4, marketing_admin: 5, guest: 6}
2.In角色表，现在我们将有ID user_id role_id
替代品＃2
1.创建2个模型Role and Role_User。
角色表将只包含ID | role_name和ROLE_USER将包含ID | user_id | role_id
这应该是首选？
单独表的一个额外好处是用户可以有多个角色，如果这是您的系统需要的东西。另外，将不同角色存储在数据库中应该更好地执行数据库级别的数据完整性，即不能向用户添加不存在的角色。
如果您确实最终为角色和连接表使用单独的表，请确保为连接表添加适当的索引。
除此之外，它确实取决于上下文和用例。如果系统足够简单，那么使用枚举方式就没有问题。
无理由多个角色不能被硬编码 – Andrew
我会建议去第二种方法，就好像将来有任何额外角色的可能性一样，您将不会有任何负担来创建额外的角色。使用第一种方法，您必须编辑您的枚举以获得您未来可能需要添加的其他角色
这取决于如何将角色烘焙到您的代码中。一些系统有一个非常严格的“管理员”或“主持人”或“用户”的概念，引入不适合这些插槽的角色会导致混乱。在这些情况下，他们最好离开硬编码。你可能只有一个表格来将内部名称转换为标签，这在涉及翻译时尤为重要。 “管理员”变成了“管理员”，或者其他语言中的任何含义。
如果你有一个适应性更强的系统，角色表可以定义任意权限，那么它就更有意义了。您可以创建可在系统结构中工作的自定义角色，因为系统是专门为其设计的。这种情况下的“角色”只是一组权限。
我不认为这有一些具体的规则。这是对特定系统和个人偏好的更多估计。就个人而言，我更喜欢单独的表，而不是随时关注枚举。 –
存储在数据库上意味着任何拥有SQL（报告，独立SQL查询等）的人都可以使用这些数据，但我更喜欢从性能角度来看enum。选择3是做两个，它涵盖所有基地，但增加额外的工作。 –
我建议采用第二种方法，因为它可以让您灵活地添加新角色而无需更改和部署应用程序代码。保持实体清晰分离总是好的。 – money