用于存储角色的枚举与单独的表？ [关闭]答案

【问题标题】：enum vs separate table for storing roles? [closed]用于存储角色的枚举与单独的表？ [关闭]
【发布时间】：2017-07-04 06:25:41
【问题描述】：

我必须在我的应用中实现角色系统以进行授权。我们的系统中有大约 5 种角色。

为了维持这些角色，我们有 2 个选择，

备选方案#1

1.在rails角色模型中创建枚举，

enum role: {super_admin: 1, translator: 2, approver: 3, sales_admin: 4, marketing_admin: 5, guest: 6}

2.在 Roles 表中，现在我们将有 ID user_id role_id

备选方案#2

1.创建2个模型Role and Role_User。

Role 表将仅包含 ID | role_name 而 Role_User 将包含 ID | user_id | role_id

应该首选哪个？

【问题讨论】：

我认为这没有什么特定的规则。这更多的是您对特定系统和个人偏好的估计。就个人而言，我更喜欢单独的表格而不是枚举
存储在数据库中意味着任何使用 SQL（报告、独立 SQL 查询等）的人都可以使用数据，但从性能的角度来看，我更喜欢枚举。备选方案 3 是两者都做，这涵盖了所有基础但增加了额外的工作。
我建议采用第二种方法，因为它可以让您灵活地添加新角色，而无需更改和部署应用程序代码。此外，保持实体清晰和分离总是好的。

标签： mysql ruby-on-rails ruby-on-rails-4 enums

【解决方案1】：

我建议采用第二种方法，就好像将来有任何额外角色的可能性一样，您将没有负担创建该额外角色。使用第一种方法，您必须为将来可能要添加的其他角色编辑枚举

【讨论】：

【解决方案2】：

这取决于角色在代码中的融入程度。一些系统对“管理员”或“版主”或“用户”有非常严格的概念，并且引入不适合这些位置的角色可能会导致混乱。在这些情况下，最好保留硬编码。您可能有一个表来简单地将内部名称转换为标签，这在涉及翻译时尤其重要。 “admin”变成“Administrator”，或者在您的系统使用的其他语言中的任何含义。

如果您有一个适应性更强的系统，角色表可以定义任意权限，那么它就更有意义了。您可以创建将在系统结构内工作的自定义角色，因为系统是专门为它设计的。在这种情况下，“角色”只是一组权限。

【讨论】：

【解决方案3】：

单独表格的另一个好处是用户可以拥有多个角色，如果这是您的系统需要的话。此外，在数据库中存储不同的角色应该更好地执行数据库级别的数据完整性，即您不能向用户添加不存在的角色。

如果您最终使用单独的角色表和连接表，请务必为连接表添加正确的索引。

除此之外，它实际上取决于上下文和用例。如果系统足够简单，那么采用枚举方式并没有错。

【讨论】：

没有理由不能硬编码多个角色