建議開發員少用帶錶連結的檢視(此檢視非物化檢視)

之前雖然說過快可以專心搞試驗了
但誰曾想馬上就分過來許多的任務
而且，大多數是煩人、無聊的體力式任務

不過，今天利用了幾分鐘的閒暇時間
驗證了一個以前看過文件的東西：檢視(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/，如需轉載，請註明出處，否則將追究法律責任。