带有查找表说明的位掩码标志

Question

我收到了来自外部来源的数据集，其中包含多个位掩码字段作为 varchars。它们的长度低至 3，长至 21 个值。我需要能够使用 AND 或 OR 逻辑基于这些字段运行 SELECT 查询。

使用计算字段，我只是将位转换为整数值，我可以通过使用简单的 WHERE rowvalue = requestvalue 轻松找到与 AND 查询匹配的行，但 OR 逻辑需要使用按位 & 才能找到匹配记录。

鉴于我需要处理其中的几个列并从数亿条记录中进行选择，我觉得在执行按位和操作来过滤我的 SELECT 结果时会产生巨大的性能损失。

我从搜索中找到了这个答案，看起来它可能符合我的需求，但我需要澄清一下它是如何实现的。

这是否像创建具有所有可能搜索条件的查找表一样简单？

使用 (a & b) 的 3 位示例（编辑：按位操作错误）

001,001
001,011
001,101
001,111
010,010
010,011
010,110
011,011
011,111
etc

作者提到它最初是违反直觉的，但我不禁觉得我对解决方案的解释不正确，因为这会给我一个可能有数十亿行的查找表。

对我上面链接的答案的任何澄清或其他可以保留现有数据库的建议表示赞赏。

编辑：使用小数据的更具体示例。

四个标志，HasHouse、HasCar、HasCat、HasDog，0000 是没有，1111 是全部。

可以翻转任意数量的标志，从全部到无，并且必须过滤选择匹配所有（使用精确值比较）或至少 1（使用按位 &）的结果。

为每个位掩码添加一个计算列是可以的，但是为超过 100 位的每个位添加一列，再加上如何插入/更新数据是我试图寻找替代解决方案的原因。

Answer 1

我部分同意 Aaron 的评论 - 在存储 21 条不相关信息的最常见情况下，您可能会使用 21 位列。作为通用解决方案，它很可能是您的最佳解决方案。如果您有多个位掩码 varchar 列，那么这将转换为可能具有一百多个位标志的行。仅供参考，当您未将 21 位定义为 NULLable 时，它​​们将存储为 3 个字节，从而消除了 NULL 位图中空间的必要性。由于您有多个位掩码列，因此最终会将每 8 位混合为一个字节。

SQL Server 最终对多列查询所做的事情最终是一堆位掩码例程（是的！SQL Server 使用位掩码，因此它们的概念本身不可能都是坏的！）但对于一般用例来说，它使生活变得简单对你来说更容易。

如果我们有更多关于您运行的查询类型的信息，我们也许能够提供更好的建议，因为最终用例决定了设计。

如果您坚持使用 COMPUTED 列，如果您还没有这样做，我会坚持并索引它。它有助于一些查询，例如

1. 精确匹配

   WHERE ComputedInt = POWER(2, 6) -- 位位置 7

2. 第 15 位进行 AND 匹配，其他 2 位（第 10 位和第 7 位）进行 OR 匹配

   其中计算型 Int >= Power(2,14) 和计算型 Int < 功率(2,15) 和计算型 Int & (Power(2,9) + Power(2,6)) > 0

但这些可能是奇异的样本，但在某些情况下也是真实存在的。它当然不会比 21 个单独的位列差太多，是的，您的语句可能更容易编写，但请记住 SQL Server 已将它们混合在一起存储为 3 个字节，并且无论如何都会进行位取消屏蔽！您可能会想，如果位掩码都不好 （无一例外），那么 SQL Server 就不会这样做，对吧？

编辑

重新的场景

四个标志，HasHouse、HasCar、HasCat、HasDog，0000 表示没有，1111 表示全部。

一次测试所有 4 位并执行基于单个整数的操作会更有效且逻辑上更方便，例如

WHERE computedInt & (POWER(2,10)+POWER(2,5)+POWER(2,3)+POWER(2,1)) = 0 -- has none
WHERE computedInt & (POWER(2,10)+POWER(2,5)+POWER(2,3)+POWER(2,1)) > 0 -- has one or more

假设，如果这是您对表最常使用的查询，您甚至可以将四列分组到另一个计算列中并单独对其进行索引，从而不需要位掩码（只需使用 和 测试结果 int =0）>0。您甚至可以更进一步，预先计算答案……课程的马匹。