对于许多复选框来说，是多列还是单列位字符串更好答案

【问题标题】：Is it better to have many columns or a single column bit string for many checkboxes对于许多复选框来说，是多列还是单列位字符串更好
【发布时间】：2018-10-31 03:55:02
【问题描述】：

我有以下场景：

一个包含许多复选框的表单，大约 100 个。

关于如何将它们保存在数据库中，我有 2 个想法：

1。多列

我创建了一个如下所示的表格：

id | box1 | box2 | ... | box100 | updated| created

id: int
box1: bit(1)


SELECT * FROM table WHERE box1 = 1 AND box22 = 1 ...

2。单个数据列

表格很简单：

id | data | updated | created

data: varchar(100)

SELECT * FROM table WHERE data LIKE '_______1___ ... ____1____1'

其中数据看起来像0001100101010......01，每个字符表示是否检查了值。

考虑到该表将有 200k+ 行，这是一种更具可扩展性的解决方案？

3。 JSON 类型的单个数据列

我还没有这方面的好消息。

【问题讨论】：

更好的安排是每个盒子都有一张桌子，当盒子被打勾时，它只保留主桌子的钥匙。
您建议的方案都不能很好地扩展。
如果您的解决方案导致您每次添加/删除控件时都必须使用数据库架构（添加/删除列/表），那么您的架构是错误的。如果您的架构导致您必须解析列以获取值（并在您添加更多控件时中断），那么这是一个糟糕的架构。 id | form_submission_id | control_id | value 在这里会更有意义。您提交的带有 100 个复选框/控件的表单将生成 100 条记录。可扩展。可转位。完成。
20M。那不是大数据。那里不用担心。数据库意味着有很多记录。这就是为什么存在索引、分区、统计数据集合、无共享架构以及所有其他数据库调优的原因。您可以使用的调优工具旨在处理大量记录，而不是处理大量列或大量表。
这就像我必须在泰坦尼克号和卢西塔尼亚号之间选择我想乘坐的历史船只。第一列...我想。只是因为使用二进制/位掩码单列解决方案，如果您添加了一个新列，那么您的字符在字符串中的位置（或位掩码中的位）要么必须更新（yuck）要么在您的代码中进行补偿。这意味着每次您的应用程序更改时，您都会有一个历史补丁。另外，您必须有代码来处理跟踪字符串/位掩码中字符/位的位置。

标签： mysql database-performance query-performance sqlperformance

【解决方案1】：

或者……

4.几个SETs

5.几个INTs

这些更紧凑：每个字节大约 8 个复选框。
设置/测试它们有点乱。
由于它们仅限于 64 位，因此您需要不止一个 SET 或 INT。我建议根据应用程序对位进行分组是一种合乎逻辑的方式。
注意FIND_IN_SET()。
注意(1 << $n) 创造价值2^n。
注意| 和& 运算符。

5 个中哪个最好？这取决于您需要运行的查询——搜索（如果需要？）、插入、更新（如果需要？）和选择。

例如：对于 INTs ，WHERE (bits & 0x2C08) = 0x2C08 将同时检查 4 个标志是否为“ON”。该常量可以在应用程序代码中构造，也可以在位 3、10、11、13 中构造 ((1<<13) | (1<<11) | (1<<10) | (1<<3))。同时，忽略其他标志。如果您需要将它们设为“关闭”，则测试将是WHERE bits ^ 0x2C08 = 0。如果这两种测试中的任何一种是您的主要活动，那么选择 5 可能是性能和空间上最好的，虽然读起来有些晦涩。

添加另一个选项时，SET 需要 ALTER TABLE。 INT 通常有一些备用位（TINYINT UNSIGNED 有 8 位，...BIGINT UNSIGNED 有 64）。因此，大约八分之一的时候，您需要ALTER 来获得更大的 INT 或添加另一个 INT。删除一个选项：建议只放弃那个 SET 元素或 INT 位。

【讨论】：

最重的查询将根据条件选择（导出）。
@Lemures - 我评论说要添加另一个复选框。