有没有办法删除这种类型的 SQL SELECT 中的嵌套查询?
给定此表结构和示例数据(t3 不应在查询中使用,它仅在此处显示 t1 和 t2 之间的关系):
t1 t2 t3
-------------- ----------------- --------------------------------
| id | value | | t1key | t3key | | id | value |
| 1 | 2008 | | 3 | 1 | | 1 | "New intel cpu in 2010" |
| 2 | 2009 | | 4 | 1 | | 2 | "New amd cpu in 2008" |
| 3 | 2010 | | 6 | 1 | | | ... |
| 4 | intel | | 1 | 2 | --------------------------------
| 5 | amd | | 5 | 2 |
| 6 | cpu | | 6 | 2 |
| | ... | | | ... |
-------------- -----------------
您将如何构建满足以下条件的 SQL 查询:
Given the input for t1.id is the set {6} returns t1.id set {3,4,6,1,5}
Given the input for t1.id is the set {6,4} returns t1.id set {3,4,6}
Given the input for t1.id is the set {5,4} returns t1.id set {}
并且不会影响性能当桌子更大时......?
Given this table structure and example data (t3 should not be used in the query, it is only here to show the relation between t1 and t2):
t1 t2 t3
-------------- ----------------- --------------------------------
| id | value | | t1key | t3key | | id | value |
| 1 | 2008 | | 3 | 1 | | 1 | "New intel cpu in 2010" |
| 2 | 2009 | | 4 | 1 | | 2 | "New amd cpu in 2008" |
| 3 | 2010 | | 6 | 1 | | | ... |
| 4 | intel | | 1 | 2 | --------------------------------
| 5 | amd | | 5 | 2 |
| 6 | cpu | | 6 | 2 |
| | ... | | | ... |
-------------- -----------------
How would you build a SQL query that would satisfy the following:
Given the input for t1.id is the set {6} returns t1.id set {3,4,6,1,5}
Given the input for t1.id is the set {6,4} returns t1.id set {3,4,6}
Given the input for t1.id is the set {5,4} returns t1.id set {}
and doesn't kill performance when the tables are bigger...?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
这是我的出色贡献(至少让我们假设它现在很出色:)
IN (6,4)
部分确实是不言自明的。在cnt >=2
中,2是IN
子句中id
-s的数量。例如:您使用的是IN (6)
,那么您应该使用cnt >=1
。我不确定是否需要
>
,但我很懒,没有创建更大的数据集来测试:)Here is my brilliant contribution (at least let's assume it's brilliant for now:)
The
IN (6,4)
part is really self explanatory. In thecnt >=2
2 is the number ofid
-s in theIN
clause. For example: you're usingIN (6)
then you should usecnt >=1
.I'm not sure
>
is needed at all, but I am lazy enogh not to create a larger dataset to test on :)不太清楚你想要什么。
我将调用表 t1
word
,调用表 t3phrase
并调用表 t2word is inphrase
。那么我猜你想找到与一组特定的 word.ids 位于同一短语中的所有 word.ids。这是正确的吗?
更正
阅读乔的评论并重新阅读问题详细信息,我猜您想找到与指定列表中的所有单词出现在同一短语中的所有单词。
这看起来像一个关系除法问题:
第二个解决方案:
第三个解决方案:
注意: 第一个(带有
NON EXISTS
)解决方案与其他两个解决方案有很大区别:如果您尝试它带有一个其成员未出现在表 t2 中的列表,例如
(2)
或(2,7)
,它将显示 t2 中的所有 t1key。在这种情况下,第二个和第三个解决方案将根本不显示任何密钥。
It's not very clear what you want.
I will call table t1
word
, call table t3phrase
and call table t2word is in phrase
.Then I guess you want to find all word.ids that are in a same phrase as a specific set of word.ids. Is that correct?
CORRECTION
Reading Joe's comment and re-reading the question details, I guess you want to find all words that appear in same phrase with ALL words in your specified list.
This looks like a relational division problem:
2nd solution:
3rd solution:
Note: The first (with
NON EXISTS
) solution has a great difference with the other two:If you try it with a list that its members do not appear in table t2, say
(2)
or(2,7)
, it will show ALL t1key's from t2.The 2nd and 3rd solutions will show NO keys at all in such a case.
您需要添加更多“相交”子句,具体取决于输入集中有多少项。
在 SQL Server 上测试。
You would need to add more "intersect" clauses depending on how many items are in your input set.
Tested on SQL Server.
从 t1(关键字)开始,您将获得所有包含“cpu”(或其他内容)的 t3(表达式)。您不需要直接加入 t3,也不需要那里的任何数据。第二次加入 t2 时,您将获得找到的表达式中包含的所有其他关键字。您只需要返回它们的 t1key 即可。
更正:如果您不需要子查询,您可以为每个要搜索的关键字创建一个联接:
Starting on t1 (the keyword), you get all the t3 (expressions) which contain "cpu" (or whatever). You don't need to join t3 directly, you don't need any data from there. Joining t2 a second time you get all other keywords which are contained in the found expressions. You only need to return the t1key's of them.
Correction: If you don't want subqueries, you could create a join for each keyword to search for:
他在那里,
您确定选择了正确的表结构吗?
它似乎没有标准化 - 尽管我不确切知道每个表可以代表什么实体。
保持数据库设计至少采用第三范式非常重要(请参阅维基百科文章,
您的查询将更加自然且易于配制
He there,
Are you sure you have chosen the right table structure?
It doesn't seem to be normalized - though I don't know exactly what entity each table could represent.
Its important to keep your database design at least in the third normal form (see Wikipedia article
Your queries will be much more natural and easily formulated