摘要:SQL效能調整 View 轉實體 Table
在某些系統中可能會透過在資料庫中建 View，來簡化後續一些查詢撰寫 SQL的
複雜度，但有時候 View 裡面的定義其實過度的複雜了，在資料量成長之後引發了
一些的效能問題。治本之道當然是整個從新檢視並調整系統的資料結構與資料查詢的方式。
但在現實的專案中有時候時程與歷史的包袱，並不允許有這樣的人時去處理這樣近乎打
掉重練得動作。假設View裡面的內容在商務邏輯上也沒有絕對的即時性需求，內容也不
算太過於龐大，可以考慮一個應急的處理措施，把 View 重新定義成一個實際的 Table。
詳細的處理方式如下:
1. 假設有一個 view 名為 view_company ，
2. 可先將 view_compay 重新命名為 view_company_definition
3. 另外設定 SQL 排程，定期執行
Select * into view_company from view_company_definition
讓原本 view_company 變成一個實體的 Table . 假設包成一個 Store Procedure 來處理的話
約略可以這樣撰寫:
create PROCEDURE sp_convert_view_to_table
AS
BEGIN
set nocount on;
/*檢查 _view_company 是否存在，存在的話先 drop 掉*/
if exists(select name from sysobjects where xtype = 'U' and name = '_view_company')
drop table _view_company;
/*從 view_company_definition 產生實體 Table _view_company */
select * into _view_company
from view_company_definition;
/*補上查詢可能會用上的索引.*/
create index [IX_view_company_someinedx] ON [dbo].[_view_company] ([field1], [field1]);
/*檢查 view_company 是否存在，存在的話先 drop 掉*/
if exists(select name from sysobjects where xtype = 'U' and name = 'view_company')
drop table view_company;
/*將 _view_company 重新 rename 成 view_company */
exec sp_rename '_view_company' , 'view_company';
END
4. 處理上雖然最後的目標是 view_company ，但在處理的過程中，先不直接對 view_company 處理，
是先用另外一個 _view_company 為處理目標，最後在將處理好的 _view_company 重新命名為，
view_company ，這樣的流程可以減少再處理 view_company 中剛好有查詢要調用到 view_company
的機會。
5. 因為 我們是直接用一個實體 table 取代原本 view 的位置，所以原本程式與 SQL基本上是不受影響的
6. 但因為需配合資料庫排程，取代 view 的 table 跟實際的資料會產生一定的時間落差，至於能允許多
長的時間落差那就要看實際的商業流程決定囉。