什么时候最好将标志存储为位掩码而不是使用关联表？

Question 1

我正在开发一个应用程序，其中用户具有使用不同功能（例如读取，创建，下载，打印，批准等）的不同权限。权限列表不会经常更改。我有几个关于如何在数据库中存储这些权限的选项。

在什么情况下，选择2会更好？

选项1

使用关联表。

用户
----
用户名（PK）
名称
部

允许
----
PermissionId（PK）
名称

用户权限
----
用户ID（FK）
PermissionId（FK）

选项2

为每个用户存储一个位掩码。

用户
----
用户名（PK）
名称
部
权限

[Flags]
enum Permissions {
    Read = 1,
    Create = 2,
    Download = 4,
    Print = 8,
    Approve = 16
}

Question 2

精彩的问题！

首先，让我们对“更好”进行一些假设。

我假设您不太关心磁盘空间-从空间的角度来看，位掩码非常有效，但是我不确定如果您使用SQL Server，那么这很重要。

我假设您确实关心速度。使用计算时，位掩码可以非常快-但是查询位掩码时将无法使用索引。这没什么大不了的，但是如果您想知道哪些用户具有创建访问权限，您的查询将类似于

select * from user where permsission & CREATE = TRUE

（今天，在旅途中无法访问SQL Server）。由于数学运算，该查询将无法使用索引-因此，如果您有大量用户，这将非常痛苦。

我假设您关心的是可维护性。从可维护性的角度来看，位掩码不像底层问题域那样具有表现力，没有存储明确的权限。几乎可以肯定，您必须跨多个组件（包括数据库）同步位掩码标志的值。不是没有可能，但是背面会很痛。

因此，除非有另一种评估“更好”的方法，否则我会说位掩码路由不如将权限存储在规范化的数据库结构中那么好。我不同意它会“变慢，因为您必须进行连接”-除非您的数据库完全无法正常运行，否则您将无法进行测量（而没有有效索引的查询会变得很明显即使有几千条记录，速度也较慢）。

Question 3

就个人而言，我将使用关联表。

位掩码字段很难查询和加入。

您始终可以将其映射到C＃标志枚举，如果性能变高并发出重构数据库的请求。

可读性过早的优化;）

Question 4

存储标准化的权限（即不在位掩码中）。虽然它显然不是一个要求，为您的方案（特别是如果权限不会经常更改），它将使查询更容易和更明显。

Question 5

有没有明确的答案，所以为你做什么工作。但是，这是我的收获：

如果使用选项1

您希望权限增加到许多
如果您可能需要对数据库存储过程本身进行权限检查
您不会期望数以百万计的用户，以便表中的记录不会大量增长

如果使用选项2

权限将限于少数
您期望数百万用户

Question 6

我唯一能想到的是何时会真正使用位掩码字段存储权限的时间是，当您真正真正受限于拥有多少物理内存时……就像在旧的移动设备上一样。实际上，您节省的内存量不值得。即使是成千上万的用户，硬盘空间也很便宜，并且您可以使用非位掩码方法（这是关于报告谁拥有什么权限等）来轻松扩展权限等。

我遇到的最大麻烦之一就是直接在数据库中分配用户权限。我知道您应该尝试并使用应用程序来管理自身，而通常不使用应用程序数据，但是有时候，这只是必要的。除非位掩码实际上是一个字符字段，否则您可以轻松地查看某人具有什么权限而不是整数，请尝试向分析师等说明如何通过更新该字段来授予某人写访问权限等...并祈祷你的算术是正确的。

Question 7

当它们不会改变结构并且始终一起使用时，它将很有用。这样，您几乎不需要往返服务器。它们在性能方面也很不错，因为您可以在单个变量分配中影响所有权限。

我个人不喜欢它们...在一些性能密集的应用程序中，它们仍在使用。我记得使用这些工具来实现国际象棋AI，因为您可以在一个比较中评估一个棋盘。

Question 8

除非数据库只是为您保存记录，否则我将始终将其标准化存储，并且除了检索和保存之外，您将永远不会做任何事情。一种解决方案是在登录时获取用户的权限字符串，并在服务器代码中对其进行处理和缓存。在那种情况下，对其进行非规范化真的没什么大不了的。

如果要将其存储在字符串中并尝试在数据库级别上进行处理，则必须进行一些体操操作才能获得页面X的权限，这可能会很痛苦。

Question 9

我建议不要使用位掩码，原因如下：

索引无法有效使用
查询是更难
可读性/维护受到严重影响
那里的普通开发人员不知道什么是位掩码
灵活性降低（数字中最大位数为nr个）

根据您的查询模式，计划的功能集和数据分布，我会选择您的选项1，或者甚至是一些简单的方法：

user_permissions(
   user_id
  ,read     
  ,create   
  ,download 
  ,print    
  ,approve  
  ,primary key(user_id)
);

添加列是对模式的修改，但是我猜想添加特权“清除”将需要一些代码，因此特权可能不必像您想象的那样动态。

如果您的数据分布不佳，例如90％的用户群没有单一权限，则以下模型也可以正常工作（但是在进行较大扫描时会分崩离析（一个5向联接与一个完整表比较）扫描）。

user_permission_read(
   user_id
  ,primary key(user_id)
  ,foreign key(user_id) references user(user_id)
)

user_permission_write(
   user_id
  ,primary key(user_id)
  ,foreign key(user_id) references user(user_id)
)

user_permission_etcetera(
   user_id
  ,primary key(user_id)
  ,foreign key(user_id) references user(user_id)
)

Question 10

使用标志枚举（位掩码）将使查询运行得更快，因为您无需为了理解该值而包括关联表的联接。