一、建VIEW對SQL本身效能有何影響？？
例如，我在同一個SQL SERVER 上建兩個資料庫，TESTDB1,TESTDB2
在TESTDB1要用到TESTDB2的資料時，
依效能來說，是建VIEW比較好還是直接下語法FROM TESTDB2.DBO.TEST 呢？？
二、如果同時間要用到很多TABLE時，是用JOIN方式還是建VEIW(用聯集方法）何者，效能會比較好？

一、建VIEW的功能有點像預存程序喔會先編譯好所以速度會比較快些
是否要建VIEW或者下語法要視情況喔因為建VIEW的話每經update,delete等都會吃Server運算資源喔
所以除非是"比較複雜"且"固定用到"的報表,庫存運算等才建議建VIEW

二、要看運算的幅度如果用到的連結會做大量運算基本上用VIEW會比較快，因為直接可以用，
基本上速度都不會差非常多啦，只要有
1.良好的Table結構設計(ER,UML分析,正規化,產業資料量分析...)
2.適度的索引優化(調校)
3.資料庫,主機優化(調校)
通常速度都不會慢啦

抱歉以上的項目一可能造成誤解更正如下:
我所謂的變慢是指使用View的時候,原始的Table經過異動後在使用時必須重新抓取資料所以會吃資源若無異動時就不需要
因此建View不會影響原始Table本身,而是Table的異動程度會影響View
索引的建置才會影響Table本身的速度,如果造成誤解抱歉~

編輯記錄

所以insert、update、delete直接用語法連結(如FROM TESTDB2.DBO.TEST)會比較好囉？？
若是只查資料用建VIEW會比較好？？
建完VIEW後，有用到時才會影響SERVER的效能嗎？？
也就是說，就算我建了二十個VIEW後，沒用到的話，對於SERVER是沒差的？？
===================引 用 darnell 文 章===================
一、建VIEW的功能有點像預存程序喔會先編譯好所以速度會比較快些
是否要建VIEW或者下語法要視情況喔因為建VIEW的話每經update,delete等都會吃Server運算資源喔
所以除非是"比較複雜"且"固定用到"的報表,庫存運算等才建議建VIEW

二、要看運算的幅度如果用到的連結會做大量運算基本上用VIEW會比較快，因為直接可以用，
基本上速度都不會差非常多啦，只要有
1.良好的Table結構設計(ER,UML分析,正規化,產業資料量分析...)
2.適度的索引優化(調校)
3.資料庫,主機優化(調校)
通常速度都不會慢啦

===================引 用 jacosun 文 章===================
所以insert、update、delete直接用語法連結(如FROM TESTDB2.DBO.TEST)會比較好囉？？

經常執行異動的Table做成View在使用View時會比較吃Server資源
因此除非...此View固定會常需要用到此複雜的運算>使用時所吃的資源
比較有建VIEW的價值

若是只查資料用建VIEW會比較好？？

對,如果資料分散於多個資料表又不常異動蠻適合建成VIEW,也增加使用上的方便(不用Join一堆)

建完VIEW後，有用到時才會影響SERVER的效能嗎？？
也就是說，就算我建了二十個VIEW後，沒用到的話，對於SERVER是沒差的？？

建成VIEW之後會固定佔一些記憶體空間(載入也比較快),如果Ram大是沒影響(反正用不完)
Ram如果本來就用很多就少建些VIEW會比較好
如前面說的經常執行異動的Table做成View在使用View時會比較吃Server資源因此還是有點差但沒用到會吃的少
,數量少沒感覺數量多就知道了20個是還好

編輯記錄

===================引 用 jacosun 文 章===================
所以insert、update、delete直接用語法連結(如FROM TESTDB2.DBO.TEST)會比較好囉？？

這句補充一下不是用哪一種會比較好是都可以,
建VIEW跟用到的Table異動量才有關係所以是看從"某Table"異動頻繁角度看,而不是單純從異動角度看
好像繞口令
當然如果你原先用到Table關聯很複雜建View的效益就比較大(可以簡化使用)Server負載又不高
當然可以選擇建View嚕

編輯記錄

補充問一下 ~~
有兩個TABLE要建立VEIW，(是單頭與單身的關係)
單純只查詢的話，是建兩個VEIW 還是建一個VEIW然後JOIN 起來呢???
若有建VEIW，但是為了做異動的話 直接下語法到另一個資料庫去做異動，這樣是不是就跳過VEIW了呢??
感謝大大，費心教導 ^^ 真得是佛心來的~~~

===================引 用 darnell 文 章===================
===================引 用 jacosun 文 章===================
所以insert、update、delete直接用語法連結(如FROM TESTDB2.DBO.TEST)會比較好囉？？

這句補充一下不是用哪一種會比較好是都可以,
建VIEW跟用到的Table異動量才有關係所以是看從"某Table"異動頻繁角度看,而不是單純從異動角度看
好像繞口令
當然如果你原先用到Table關聯很複雜建View的效益就比較大(可以簡化使用)Server負載又不高
當然可以選擇建View嚕

===================引 用 jacosun 文 章===================
補充問一下 ~~
有兩個TABLE要建立VEIW，(是單頭與單身的關係)
單純只查詢的話，是建兩個VEIW 還是建一個VEIW然後JOIN 起來呢???

要視兩者緊密度，以及查詢頻繁度來看，如果這兩個Table常常固定一起用(主要做查詢用途的報表、查詢功能)又常用，
建成View使用上的確比較適合，不常一起用的就比較不適合建一堆VIew來麻煩自己了

若有建VEIW，但是為了做異動的話 直接下語法到另一個資料庫去做異動，這樣是不是就跳過VEIW了呢??
感謝大大，費心教導 ^^ 真得是佛心來的~~~

當然，View如其名，主要就是簡化多個Table之間的關係以及增加查詢的速度，因此異動當然就需另外處理
一般我們常使用程式來做多Table同步處理(當然要在相同Transation中)，如果你要求比較嚴謹，SQL又熟的話，
使用Trigger也是個不錯的方法(由資料庫來負責相關的異動)

===================引 用 darnell 文 章===================
===================引 用 jacosun 文 章===================
補充問一下 ~~
有兩個TABLE要建立VEIW，(是單頭與單身的關係)
單純只查詢的話，是建兩個VEIW 還是建一個VEIW然後JOIN 起來呢???

要視兩者緊密度，以及查詢頻繁度來看，如果這兩個Table常常固定一起用(主要做查詢用途的報表、查詢功能)又常用，
建成View使用上的確比較適合，不常一起用的就比較不適合建一堆VIew來麻煩自己了

假設有四個Table，每一個資料量不大。但是會在同一隻程式做到查詢資料。
此時，是建四個view，或者是用union方式建成一個view。(用UNION方式有沒有限制在幾個TABLE內？）
對於系統這樣的方式建四個跟建一個吃效能跟記憶體是一樣還是有差？？

若有建VEIW，但是為了做異動的話 直接下語法到另一個資料庫去做異動，這樣是不是就跳過VEIW了呢??
感謝大大，費心教導 ^^ 真得是佛心來的~~~

當然，View如其名，主要就是簡化多個Table之間的關係以及增加查詢的速度，因此異動當然就需另外處理
一般我們常使用程式來做多Table同步處理(當然要在相同Transation中)，如果你要求比較嚴謹，SQL又熟的話，
使用Trigger也是個不錯的方法(由資料庫來負責相關的異動)

（感謝大大，Trigger有在用、Procedure也有在用，就因為感覺程式在跑報表有點慢了～～所以才有此一問）

編輯記錄

===================引 用 jacosun 文 章===================
假設有四個Table，每一個資料量不大。但是會在同一隻程式做到查詢資料。
此時，是建四個view，或者是用union方式建成一個view。(用UNION方式有沒有限制在幾個TABLE內？）
對於系統這樣的方式建四個跟建一個吃效能跟記憶體是一樣還是有差？？

4個Table建4個View有何意義嗎?直接使用原始Table不是一樣?(不知有無誤解你文字上的意思)
資料少需要加速No,降低系統複雜度No,多耗些系統資源讓客戶覺得Server有在動Yes(just Joke)
所以應該是union成一個View(使用union基本上不用擔心不夠用,實際數字記不住了印象中200個以上,應該是夠用了,如果真的用不夠用了,那也應該想想是不是設計上有需要修改的地方)建一個View所花的資源當然比較省嚕,因為建成四個View分開查詢沒比較快(可能還比較慢)~

（感謝大大，Trigger有在用、Procedure也有在用，就因為感覺程式在跑報表有點慢了～～所以才有此一問）

報表會慢通常考慮調整的順序如下~
1.是否索引沒設定或不足?或設定的不適當?
2.是否SQL語法下的方式不好?是否有其他SQL語法加速方式?
3.是否主機記憶體不足?磁碟效率不好?主機負載太大?
4.是否資料切割結構當初設計的不好?

註:這是以資料庫端角度來看,整體可能的影響還有程式端的部分(ex展示運算速度,報表產生速度),網路傳輸部分(ex網路延遲)

每一項都需要不少的經驗與方法去調整嚕,抱歉這邊沒辦法說明很詳細了,不然可能得長篇大論了,所以提供給你可能的順序方向,市面上可以找到的到相關書籍(SQL語法以及Server主機的操作使用或者調校書籍),請自行參考嚕

編輯記錄

感謝大大～～您的建議已經很受用了
真得是佛心來的啦～～感恩！！
===================引 用 darnell 文 章===================
===================引 用 jacosun 文 章===================
假設有四個Table，每一個資料量不大。但是會在同一隻程式做到查詢資料。
此時，是建四個view，或者是用union方式建成一個view。(用UNION方式有沒有限制在幾個TABLE內？）
對於系統這樣的方式建四個跟建一個吃效能跟記憶體是一樣還是有差？？

4個Table建4個View有何意義嗎?直接使用原始Table不是一樣?(不知有無誤解你文字上的意思)
資料少需要加速No,降低系統複雜度No,多耗些系統資源讓客戶覺得Server有在動Yes(just Joke)
所以應該是union成一個View(使用union基本上不用擔心不夠用,實際數字記不住了印象中200個以上,應該是夠用了,如果真的用不夠用了,那也應該想想是不是設計上有需要修改的地方)建一個View所花的資源當然比較省嚕,因為建成四個View分開查詢沒比較快(可能還比較慢)~

（感謝大大，Trigger有在用、Procedure也有在用，就因為感覺程式在跑報表有點慢了～～所以才有此一問）

報表會慢通常考慮調整的順序如下~
1.是否索引沒設定或不足?或設定的不適當?
2.是否SQL語法下的方式不好?是否有其他SQL語法加速方式?
3.是否主機記憶體不足?磁碟效率不好?主機負載太大?
4.是否資料切割結構當初設計的不好?

每一項都需要不少的經驗與方法去調整嚕,抱歉這邊沒辦法說明很詳細了,不然可能得長篇大論了,所以提供給你可能的順序方向,市面上可以找到的到相關書籍(SQL語法以及Server主機的操作使用或者調校書籍),請自行參考嚕

針對junlin大所問一事,對此特做補充說明,以免可能造成的誤解以及誤用~
http://delphi.ktop.com.tw/board.php?cid=18&fid=1494&tid=96568
對於之前所發文章未詳細解說清楚的部分,若造成誤解,在此表達歉意

View基本上對於有無加入索引而有不同的性質表現
我在此對有無加入索引的View稱為標準檢視表,有加入索引的indexed View稱為索引檢視表

標準檢視表是由一個或多個表格的合併查詢後的資料查詢結果所形成的"虛擬表格",
事先寫好的一段程序，然後將它儲存在特定的資料庫內，成為資料庫的物件之一
會佔用資料庫空間，沒使用時不佔記憶體空間,因此對於基底資料表的異動,
並不會對一般檢視表造成影響

為了追求效率,我們可能會在有複雜處理的標準檢視表加入index所形成的索引檢視表
可以有效提升效能,並會在建立索引時將建立的資料儲存起來,
索引檢視表也會自動反映對基底資料表中的資料所做的修改,
對基底資料表中的資料做修改時,資料修改也會反映在索引檢視表中儲存的資料

因此對於View的使用,還是建議各位,有實際需要時再行建立,特別是索引檢視表
對於詳細的使用時機請參考
http://www.craigmullins.com/cnr_0299b.htm

There are seven primary uses for which views excel. These are:
1. to provide row and column level security
2. to ensure efficient access paths
3. to mask complexity from the user
4. to ensure proper data derivation
5. to provide domain support
6. to rename columns, and
7. to provide solutions which can not be accomplished without views

在建立與使用索引檢視表有其"相關限制",請參考微軟說明
http://www.microsoft.com/taiwan/sql/evaluation/features/indexed.htm
http://msdn.microsoft.com/zh-tw/library/aa290257(VS.71).aspx

若有未盡完善或者疏漏的地方也歡迎討論指正~

編輯記錄