MySQL：在一列中存储多个布尔值。一个tinyint(4) -vs- 几个tinyint(4)
我需要在 1 个表中存储 5 个布尔值。 每个值都可以存储为tinyint(4)。所以，有 5 个tinyint(4)。 我正在考虑将 5 个布尔值放入一个tinyint(4) 中。 我相信，每个人都比我更清楚，1 个字节可以保存 5 位，没有问题:) 第一个值可以存储为 0（假）或 1（真），第二个值可以存储为 0（假）或 2（真），第三个值可以存储为 0 或 4，第四个值可以存储为 0 或 8，第五个值可以存储为 0 或 16。 因此，如果我们将这些值的总和存储在tinyint(4) 中，我们就确切地知道 5 个布尔值。
For example, stored 21 -> 16 + 4+1.
So, if 21 is stored, we know that:
Fifth=true
Fourth=false
Third=true
Second=false
First=true.
我的问题是： 仅保留 1 个变量有意义吗？我们赢得了数据库容量（字节）和性能（少了 4 列，但这只是 4 个字节，而您实际上在同一个表中使用了 varchar(1000)），但每次我们都必须从“sum”中“提取”适当的布尔值“使用 php 函数，这种情况经常发生（假设当用户按下按钮时）。 将布尔值作为总和存储在 1 列中是否有意义，因此您有 7 列而不是 11 列？
很明显，这些值（因为该表的行数多得多，只有 2 行）不是键。
谢谢。
I need to store 5 boolean values in 1 table.
Each value could be stored as tinyint(4). So, there are 5 tinyint(4).
I'm thinking of putting 5 boolean values in one tinyint(4).
I believe, everybody knows even better than me, 5 bits could be saved in 1 byte with no problem:)
The first value could be stored as 0(false) or 1(true), the second as 0(false) or 2(true), the third as 0 or 4, fourth as 0 or 8, fifth as 0 or 16.
So, if we store the sum of that values in tinyint(4), we exactly know 5 Boolean values.
For example, stored 21 -> 16 + 4+1.
So, if 21 is stored, we know that:
Fifth=true
Fourth=false
Third=true
Second=false
First=true.
My question is:
Does it make sense to keep only 1 variable? We win db volume (bytes) and performance (4 columns less, but that's only 4 bytes whereas you have actually used varchar(1000) in the same table), but every time we have to "extract" a proper Boolean value from "sum" using php function, and that happens often (let's say when a user presses the button).
Does it all make sense to store Boolean values as a sum in 1 column or not, so you have 7 columns instead of 11?
That values, that's clear (because that table has much more rows that just 2), are not keys.
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不要这样做 - 除非该值是单个“不透明”外部数据类型，例如标志枚举 - 如果列将曾经在查询中使用，或者曾经在所述“不透明”类型之外使用：使用离散/单独的字段。（正确的类型，如jmucchiello 和 MarkR 在他们的回答中指出。）
尝试这里的“为了性能”只会让你讨厌数据库——尤其是这个数据库——当你稍后必须“修复”它或解决丑陋的方案时。 （如果您遇到性能问题，您就会知道......并且知道足够的信息，可以在提出问题之前运行性能分析。）Donald Knuth 指出这一点是对的。 97% 的事情并不重要。因此，让它变得漂亮，让数据库做它想做的事。
快乐编码。
如果我上面的内容听起来很生动，那是因为我正在努力帮助其他人避免我
做过遇到的同样的错误:-)Don't do this -- unless the value is a single "opaque" external data-type, such as a Enum of flags -- if the columns will ever be used in a query or will ever be used outside of said "opaque" type: use discrete/separate fields. (Of the correct type, as jmucchiello and MarkR noted in their answers.)
Trying "for performance" here will just make you loath databases -- and this one in particular -- when you have to "fix" it or work around the ugly scheme later. (If you have a performance problem you'll know it ... and know enough to run a performance analysis before asking.) Donald Knuth was right when he pointed out that 97% of stuff Just Doesn't Matter. So make it pretty and let the database do what it feels like doing.
Happy coding.
If I sound animated above, it's because I'm trying help others avoid the same mistakes I've
donerun into :-)不，这没有意义。
要么将每个存储在自己的列中，要么使用 MySQL 特定的 SET 类型，该类型在内部使用位字段，但更易于人类阅读。
担心每行几个字节确实是一个坏主意。这是一个令人难以置信的过早优化的例子。
No, it does not make sense.
Either store each in its own column, OR use the MySQL-specific SET type, which internally uses bitfields, but is more human-readable.
Worrying about a few bytes per row is really a bad idea. It is a case of incredibly premature optimisation.
为什么不使用 BIT 类型 并让MySQL 担心优化空间吗？
Why don't you use the BIT Type and let MySQL worry about optimizing for space?