建议开发员少用带表链接的视图(此视图非物化视图)

之前虽然说过快可以专心搞试验了
但谁曾想马上就分过来许多的任务
而且，大多数是烦人、无聊的体力式任务

不过，今天利用了几分钟的闲暇时间
验证了一个以前看过文档的东西：视图(View)
主要目的是，求证此数据库对象对于数据库性能通常会造成影响的观点
以前只是通过文档知道了对视图检索时
视图外的条件是要在选择了视图内容后才起作用的
比如有个视图：
CREATE VIEW V_TEST AS
SELECT TB1.C1,TB1.C2,TB2.C3
FROM TB1 INNER JOIN TB2
ON TB1.TB1_ID=TB2.TB2_ID
此视图是有两个表进行链接后行程的
而当使用下列SQL进行查询时：
SELECT C1,C3 FROM V_TEST
WHERE T_TB1_ID=256
在Oracle内部，并不会把WHERE的条件带入视图中
而是先得到V_TEST视图内两个表链接之后的结果集
然后再对得到的结果集进行条件匹配
试想，如果视图中用到的两个表，都是百万数量级以上(也许用不了这么大)
那Oracle便会先去通过链接条件找出两个百万级表的相应结果
这种运算是很耗性能的，而且也不是我们所希望的过程
此时如从性能考虑，应把原视图改为相应的SQL：
SELECT TB1.C1,TB2.C3
FROM TB1 INNER JOIN TB2
ON TB1.TB1_ID=TB2.TB2_ID
WHERE TB1_ID=256

本来以为这个信息应该是大多数开发员都清除的
可没想到，在今天的一个3人小商谈中，当我提出这个意见的时候
竟然没有被公司的一位技术副主管认可……无语……
可惜当时公司的DBA不在场，不然多少可以支持一下我的观点 ◎◎
以后找机会再把自己的试验情况展示给副主管吧

视图，对于一些开发员来说，可以起到简化开发的作用
以前的单位，也有一些开发员会要求数据库人员编写一个逻辑较复杂的视图
然后在程序端就能简单的进行编程了
如果视图本身只是对某一个表进行复杂处理，性能消耗倒不是特别严重
(还是有损耗的，对几万个记录进行复杂处理，对几十个记录复杂处理，哪个更快？)
而当视图存在表链接，差距就会更明显
如果系统只是十万级以下的数据量，那倒还凑合
但对于一些中大型并发系统，造成的影响将是巨大的
所以，对于视图的使用，也是要有所限制的

今天在做任务的时候，还遇到了一个问题
在存储过程中组建动态SQL时，最终行程的SQL如果加上伪列ROWNUM
语句中的某个嵌套表链接就会找不到匹配数据，去了ROWNUM，一切正常
这个问题弄了半天，可惜最终也没有找到原因……
最终组长用另一种办法绕开了这个问题
先记下来，等把手头的活儿忙完要仔细看看

虽然近期还有一堆乱七八糟的任务
但报表组已经开始进行物化视图的初步建立
等过1、2周有些成果再总结一下吧～

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/556359/viewspace-609372/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/556359/viewspace-609372/