我有以下场景：
有许多复选框的窗体，大约100个。
关于如何将它们保存在数据库中，我有两个想法：
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 表示值是否被选中的每个字符。
考虑到表将有200000多行，哪种解决方案更具可扩展性？
3. json类型的单个数据列
我还没有这方面的好消息。
1条答案
按热度按时间cuxqih211#
或者。。。
4少许
SETs5少许INTs它们更加紧凑：每个字节大约有8个复选框。它们设置/测试起来有点乱。
因为它们被限制为64位，所以需要不止一个
SET或者INT. 我建议根据应用程序对位进行分组是一种合乎逻辑的方法。注意
FIND_IN_SET().注意
(1 << $n)为创造价值2^n.注意
|以及&操作员。这五个中哪一个最好？这取决于您需要运行的查询——搜索（如果需要）、插入、更新（如果需要）和选择。
例如：for
INTs,WHERE (bits & 0x2C08) = 0x2C08将同时检查是否有4个标志处于“打开”状态。该常量可以在应用程序代码中构造，也可以((1<<13) | (1<<11) | (1<<10) | (1<<3))对于第3、10、11、13位。同时，忽略其他标志。如果你需要他们“关闭”，测试将是WHERE bits ^ 0x2C08 = 0. 如果这两种测试中的任何一种都是您的主要活动，那么选项5可能是性能和空间方面最好的，尽管读起来有点晦涩难懂。添加其他选项时，
SET需要ALTER TABLE.INT通常有一些备用零件(TINYINT UNSIGNED有8位。。。BIGINT UNSIGNED有64个）。所以，大概八分之一的时间，你需要ALTER删除一个选项：建议放弃这个集合元素或一个int位。