如何在php中使用MySQL按位运算?
我正在尝试使用 MySQL 按位运算进行查询,我有以下示例:
table1
id ptid
1 3
2 20
3 66
4 6
table2
id types
1 music
2 art
4 pictures
8 video
16 art2
32 actor
64 movies
128 ..
...
现在,table1
中的 id = 3
是“66”,这意味着它有 64 或电影
和2 或艺术
但
他不是也有两次32 或演员
和2 或艺术
吗?
希望你能明白我的困惑在哪里。我如何控制我想要返回的结果。在这种情况下,我想要 64 或电影
和 2 或艺术
。
但有时我希望 table2
中的三个 id
属于 table1
中的 id
有什么想法吗?
谢谢
im trying to use MySQL bitwise operations for my query and i have this example:
table1
id ptid
1 3
2 20
3 66
4 6
table2
id types
1 music
2 art
4 pictures
8 video
16 art2
32 actor
64 movies
128 ..
...
now, the id = 3
from table1
is '66', witch means that it has 64 or movies
and 2 or art
but
doesn't he also have 32 or actor
twice and 2 or art
??
hope you see where my confusion is. How do i control what result i want back. In this case i want 64 or movies
and 2 or art
.
But sometimes i want three id's
from table2
to belong to an id
from table1
any ideas?
Thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
使用按位 OR
以下查询返回表 2 中
66
中的所有项目:但是 32 + 32 = 64?
虽然 32 + 32 = 64 ,对我们没有影响。
这是二进制的 64:
这是二进制的 32:
这是二进制的 2:
这是我们在本例中使用的 1 的位置,而不是值。不会有任何两个。每个标志要么打开,要么关闭。
这是二进制的 66。请注意,64 和 2 已打开,而不是 32:
使用按位 AND 而不是 OR
另一种编写查询的方法是使用按位 AND,如下所示:
因为
0 = false
到MySQL,可以进一步缩写为:Using bitwise OR
The following query returns all the items from table 2 in
66
:But 32 + 32 = 64?
Though 32 + 32 = 64, it doesn't affect us.
Here's 64 in binary:
Here's 32 in binary:
Here's 2 in binary:
It's the position of the 1 that we use in this case, not the value. There won't be two of anything. Each flag is either on or off.
Here's 66 in binary. Notice that 64 and 2 are turned on, not 32:
Using bitwise AND instead of OR
Another way to write the query is with bitwise AND like this:
Since
0 = false
to MySQL, it can be further abbreviated like this:尽管关于如何在 MySQL 中执行按位运算的问题已经得到解答,但评论中关于为什么这可能不是最佳数据模型的子问题仍然悬而未决。
在给出的示例中有两个表;一个带有位掩码,另一个带有每个位代表的细分。这意味着,在某些时候,两个表必须连接在一起才能返回/显示各个位的含义。
这种连接要么是显式的,例如
,要么是隐式的,您可以从
table1
中选择数据到您的应用程序中,然后进行第二次调用来查找位掩码值,例如,这些选项都不是想法,因为它们不是“sargable”,即数据库无法构造搜索 ARGument。因此,您无法使用索引优化查询。查询的成本超出了无法利用索引的范围,因为对于表中的每一行,数据库必须计算和评估表达式。这很快就会变得非常内存、CPU 和 I/O 密集型,并且如果不从根本上改变表结构就无法对其进行优化。
除了完全无法优化查询之外,读取数据、报告数据也可能很尴尬,并且您还可能会遇到添加更多位的限制(8 位列中的 64 个值现在可能没问题,但不一定总是如此)因此,它们也使系统难以理解,并且我认为这种设计违反了第一范式,
尽管在数据库中使用位掩码通常是糟糕设计的标志,但有时使用它们是可以的。确实是一对多关系 您
实现这种类型关系的典型方法如下所示:
将这样查询数据
根据这些表的访问模式,您通常会将关系表上的两列索引为复合索引(我通常将它们视为复合主键。)该索引将允许数据库快速查找关系表中的相关行,然后查找表2中的相关行。
Although the question on how to perform bitwise operations in MySQL has been answered, the sub-question in the comments about why this may not be an optimal data model remains outstanding.
In the example given there are two tables; one with a bitmask and one with a break down of what each bit represents. The implication is that, at some point, the two tables must be joined together to return/display the meaning of the various bits.
This join would either be explicit, e.g.
Or implicit where you might select the data from
table1
into your application and then make a second call to lookup the bitmask values e.g.Neither of these options are ideas because they are not "sargable" that is, the database cannot construct a Search ARGument. As a result, you cannot optimize the query with an index. The cost of the query goes beyond the inability to leverage an index since for every row in the table, the DB must compute and evaluate an expression. This becomes very Memory, CPU and I/O intensive very quickly and it cannot be optimized without fundamentally changing the table structure.
Beyond the complete inability to optimize the query, it can also be awkward to read the data, report on the data, and you also potentially run into limits adding more bits (64 values in an 8 bit column might be fine now but not necessarily always so. They also make systems difficult to understand, and I would argue that this design violates first normal form.
Although using bitmasks in a database is often a sign of bad design, there are times when it's fine to use them. Implementing a many-to-many relationship really isn't one of those times.
The typical approach to implementing this type of relationship looks something like this:
And you would query the data thusly
Depending on the access pattern of these tables, you would typically index both columns on the relationship table as a composite index (I usually treat them as a composite primary key.) This index would allow the database to quickly seek to the relevant rows in the relationship table and then seek to the relevant rows in table2.
在研究了 Marcus Adams 的答案后,我想我应该提供另一个例子来帮助我理解如何使用按位运算连接两个表。
考虑以下示例数据,它定义了一个元音表和一个单词表,其中单个值表示该单词中存在的元音。
现在,我们可以将
Vowel
表连接到Word
表,如下所示:当然,我们可以将任何条件应用于内部查询。
After playing around with the answer from Marcus Adams, I thought I'd provide another example that helped me understand how to join two tables using bitwise operations.
Consider the following sample data, which defines a table of vowels, and a table of words with a single value representing the vowels present in that word.
We can now join the
Vowel
table to theWord
table like so:And of course we can apply any conditions to the inner query.