SQL-CE 可能存在错误吗?
如果我运行此查询,所有 [data].* 值都会显示为 NULL。 忽略*
,这只是一个测试
SELECT
[map].*,
[data].*
FROM
f_normalised_report_hierarchy AS [map]
LEFT JOIN
f_normalised_report_data AS [data]
ON (([data].level1_id = [map].level1_id) OR ([data].level1_id = 0))
AND (([data].level2_id = [map].level2_id) OR ([data].level2_id = 0))
AND (([data].level3_id = [map].level3_id) OR ([data].level3_id = 0))
AND (([data].level4_id = [map].level4_id) OR ([data].level4_id = 0))
AND (([data].level5_id = [map].level5_id) OR ([data].level5_id = 0))
AND (([data].level6_id = [map].level6_id) OR ([data].level6_id = 0))
AND ([data].metric_id = 22)
WHERE
[map].level1_id = 22
但是,如果我在每个[之前添加
!?!?1=1 AND
,它就可以正常工作data].levelX_id = 0
SELECT
[map].*,
[data].*
FROM
f_normalised_report_hierarchy AS [map]
LEFT JOIN
f_normalised_report_data AS [data]
ON (([data].level1_id = [map].level1_id) OR (1=1 AND [data].level1_id = 0))
AND (([data].level2_id = [map].level2_id) OR (1=1 AND [data].level2_id = 0))
AND (([data].level3_id = [map].level3_id) OR (1=1 AND [data].level3_id = 0))
AND (([data].level4_id = [map].level4_id) OR (1=1 AND [data].level4_id = 0))
AND (([data].level5_id = [map].level5_id) OR (1=1 AND [data].level5_id = 0))
AND (([data].level6_id = [map].level6_id) OR (1=1 AND [data].level6_id = 0))
AND ([data].metric_id = 22)
WHERE
[map].level1_id = 22
我几乎可以接受它作为一个软糖来让它工作,但现在它需要永远运行。 (从不到一秒到 6 分钟后“仍在运行”。)
我被绑定了吗?还是 SQL CE 已经失效了?
编辑
如果我颠倒条件:
AND (([data].level6_id = [map].level6_id) OR ([data].level6_id = 0))
那么
AND (([data].level6_id = 0) OR ([data].level6_id = [map].level6_id))
我会得到不同的行为。
如果我使用 IN
代替:
AND ([data].level6_id IN ([map].level6_id,0))
我仍然会得到不同的行为。
没有任何行为有意义,当然也不是我编码的。
If I run this query, all of the [data].* values come out as NULL.
ignore the *
, it's just a test
SELECT
[map].*,
[data].*
FROM
f_normalised_report_hierarchy AS [map]
LEFT JOIN
f_normalised_report_data AS [data]
ON (([data].level1_id = [map].level1_id) OR ([data].level1_id = 0))
AND (([data].level2_id = [map].level2_id) OR ([data].level2_id = 0))
AND (([data].level3_id = [map].level3_id) OR ([data].level3_id = 0))
AND (([data].level4_id = [map].level4_id) OR ([data].level4_id = 0))
AND (([data].level5_id = [map].level5_id) OR ([data].level5_id = 0))
AND (([data].level6_id = [map].level6_id) OR ([data].level6_id = 0))
AND ([data].metric_id = 22)
WHERE
[map].level1_id = 22
Yet, it works fine if I add 1=1 AND
before each [data].levelX_id = 0
!?!?
SELECT
[map].*,
[data].*
FROM
f_normalised_report_hierarchy AS [map]
LEFT JOIN
f_normalised_report_data AS [data]
ON (([data].level1_id = [map].level1_id) OR (1=1 AND [data].level1_id = 0))
AND (([data].level2_id = [map].level2_id) OR (1=1 AND [data].level2_id = 0))
AND (([data].level3_id = [map].level3_id) OR (1=1 AND [data].level3_id = 0))
AND (([data].level4_id = [map].level4_id) OR (1=1 AND [data].level4_id = 0))
AND (([data].level5_id = [map].level5_id) OR (1=1 AND [data].level5_id = 0))
AND (([data].level6_id = [map].level6_id) OR (1=1 AND [data].level6_id = 0))
AND ([data].metric_id = 22)
WHERE
[map].level1_id = 22
I could almost live with that as a fudge to make it work, but it now takes forever to run. (Up from under a second to 'still running' after 6 minutes.)
Am I being bind? Or is SQL CE off it's rocker?
EDIT
If I reverse the conditions:
AND (([data].level6_id = [map].level6_id) OR ([data].level6_id = 0))
to
AND (([data].level6_id = 0) OR ([data].level6_id = [map].level6_id))
then I get different behaviour.
And if I use IN
instead:
AND ([data].level6_id IN ([map].level6_id,0))
I get different behaviour still.
None of the behaviours which sense, and certainly not what I have coded.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我猜这些可能会慢一些,但我让这两个查询都可以工作:
并且
使用 Compact 4 进行编辑(如果有影响的话)。
I'm guessing these are likely slower, but I got both of these queries to work:
And
EDIT With Compact 4 if it makes a difference.
我的解决方案是放弃 SQL-CE 并在客户端的内存中进行连接。
唯一有效的选项是最后一个,由于对两个表的全面扫描,实际数据的性能令人震惊。
My solution is to abandon SQL-CE and do the join in memory in the client.
The only option that works is the last one, and performance on real data was appalling due to full scans of both tables.