QUOTE:

---

原帖由 junsansi 于 2008-9-9 10:43 发表
to:nf
不奇怪，rownum固化结果集，不好使才叫奇怪~~

---

嗯, 有道理.

先收藏

MARK

强贴帮顶！学习！

QUOTE:

---

原帖由 nyfor 于 2008-9-9 10:40 发表

1000次调用和10次调用当然有性能上的区别, 我说的不太重要的原因是说 不会影响到结果的正确性, 也就是说至少不会让我们的代码出现BUG.

---

嗯，看出来了，你的目标就是没有蛀牙。接下来你也许就会追求美白了

任何秘技和偏方的存在都说明ORACLE的优化器还有可改善的余地。如果11G能够让我们摈弃SELECT (SELECT f(x) FROM DUAL) ... 这种怪怪的写法，那倒是一种进步。

QUOTE:

---

原帖由 dreamroot 于 2008-9-9 10:24 发表
虽然我是菜鸟，但感觉你的研究很无聊和没有必要性。一般很少有人会用dbms_random.value进行随机查询的。而且在dbms_random.value

---

的确如您所言，where dbms_random.value<dbms_random.value 没有任何实用意义，这纯粹就是为了好玩。其中的乐趣等你多写一些不好玩的代码，就会慢慢体会到了。
这个看似无聊的问题引发了一些有实用意义的探索，其价值参见我#26的结论。
如果你做了几年开发仍然无法体会到这些乐趣和价值，那么恭喜你！你证明了自己适合当领导！

看得我发晕

刚才试了下，NO_MERGE HINT确实起作用了，但它不能防止ORACLE把  filter("N"=1) 改写为 filter("PKG"."INC_N"()=1)，因此出来的答案总是不对劲。

任何分析函数也能够和ROWNUM一样起作用：

exec pkg.reset_n;

select * from (select pkg.inc_n n, count(*) over() from t) v where n = 1;

能否做几个 9I 下DETERMINISTIC函数的试验？

[ 本帖最后由 newkid 于 2008-9-10 07:34 编辑 ]

QUOTE:

---

原帖由 newkid 于 2008-9-9 21:50 发表


嗯，看出来了，你的目标就是没有蛀牙。接下来你也许就会追求美白了

任何秘技和偏方的存在都说明ORACLE的优化器还有可改善的余地。如果11G能够让我们摈弃SELECT (SELECT f(x) FROM DUAL) ... 这种怪怪的写法，那倒是一种进步。

---

嗯, 有道理, 刚开始正常书写SQL, 发现结果错误, 理所当然的是先要求结果的正确性, 但当出现性能问题后, 就会去追求所谓的"美白"了