總結在SQL Server檢視管理中限制條件

通過檢視來訪問資料，其優點是非常明顯的。如可以起到資料保密、保證資料的邏輯獨立性、簡化查詢操作等等。

　　但是，話說回來，SQL Server資料庫中的檢視並不是萬能的，他跟表這個基本物件還是有重大的區別。在使用檢視的時候，需要遵守四大限制。

　　限制條件一：檢視資料的更改

　　當使用者更新檢視中的資料時，其實更改的是其對應的資料表的資料。無論是對檢視中的資料進行更改，還是在檢視中插入或者刪除資料，都是類似的道理。但是，不是所有檢視都可以進行更改。如下面的這些檢視，在SQL Server資料庫中就不能夠直接對其內容進行更新，否則，系統會拒絕這種非法的操作。

　　如在一個檢視中，若採用Group By子句，對檢視中的內容進行了彙總。則使用者就不能夠對這張檢視進行更新。這主要是因為採用Group By子句對查詢結果進行彙總在後，檢視中就會丟失這條紀錄的物理儲存位置。如此，系統就無法找到需要更新的紀錄。若使用者想要在檢視中更改資料，則資料庫管理員就不能夠在檢視中新增這個Group BY分組語句。

　　如不能夠使用Distinct關鍵字。這個關鍵字的用途就是去除重複的紀錄。如沒有新增這個關鍵字的時候，檢視查詢出來的紀錄有250條。新增了這個關鍵字後，資料庫就會剔除重複的紀錄，只顯示不重複的50條紀錄。此時，若使用者要改變其中一個資料，則資料庫就不知道其到底需要更改哪條紀錄。因為檢視中看起來只有一條紀錄，而在基礎表中可能對有的紀錄有幾十條。為此，若在檢視中採用了Distinct關鍵字的話，就無法對檢視中的內容進行更改。

　　如果在檢視中有AVG、MAX等函式，則也不能夠對其進行更新。如在一張檢視中，其採用了SUN函式來彙總員工的工資時，此時，就不能夠對這張表進行更新。這是資料庫為了保障資料一致性所新增的限制條件。

　　可見，試圖雖然方便、安全，但是，其仍然不能夠代替表的地位。當需要對一些表中的資料進行更新時，我們往往更多的通過對錶的操作來完成。因為對檢視內容進行直接更改的話，需要遵守一些限制條件。在實際工作中，更多的處理規則是通過前臺程式直接更改後臺基礎表。至於這些表中資料的安全性，則要依靠前臺應用程式來保護。確保更改的準確性、合法性。

　　限制條件二：定義檢視的查詢語句中不能夠使用某些關鍵字

　　我們都知道，檢視其實就是一組查詢語句組成。或者說，檢視是封裝查詢語句的一個工具。在查詢語句中，我們可以通過一些關鍵字來格式化顯示的結果。如我們在平時工作中，經常會需要把某張表中的資料跟另外一張表進行合併。此時，資料庫管理員就可以利用Select Into語句來完成。先把資料從某個表中查詢出來，然後再新增到某個表中。

　　當經常需要類似的操作時，我們是否可以把它製作成一張檢視。每次有需要的時候，只需要執行這個檢視即可，而不用每次都進行重新書寫SQL程式碼。不過可惜的是，結果是否定的。在SQL Server資料庫的檢視中，是不能夠帶有Into關鍵字。如果要實現類似的功能，只有通過函式或者過程來實現。

　　另外，跟Oracle資料庫不同的是，在微軟的SQLServer資料庫中建立檢視的時候，還有一個額外的限制。就是不能夠在建立檢視的查詢語句中，使用order by排序語句。這是一個很特殊的規定。一些Oracle的資料庫管理員，在使用SQL Server資料庫建立檢視的時候，經常會犯類似的錯誤。他們就搞不明白，為什麼Oracle資料庫中可行，但是在微軟的資料庫中則行不通呢?這恐怕只有微軟資料庫產品的設計者才能夠回答的問題。總之我們要記住的就是，在SQLServer資料庫中，建立檢視時，查詢語句中不能夠包含Order By語句。

　　限制條件三：要對某些列取別名，並保證列名的唯一

　　在表關聯查詢的時候，當不同表的列名相同時，只需要加上表的字首即可。不需要對列另外進行命名。但是，在建立檢視時就會出現問題，資料庫會提示 “duplicate column name”的錯誤提示，警告使用者有重複的列名。有時候，使用者利用Select語句連線多個來自不同表的列，若擁有相同的名字，則這個語句仍然可以執行。但是，若把它複製到建立檢視的視窗，建立檢視時，就會不成功。

　　查詢語句跟建立檢視的查詢語句還有很多類似的差異。如有時候，我們在查詢語句中，可能會比較頻繁的採用一些算術表示式;或者在查詢語句中使用函式等等。在查詢的時候，我們可以不給這個列“取名”。資料庫在查詢的時候，會自動給其命名。但是，在建立檢視時，資料庫系統就會給你出難題。系統會提醒你為列取別名。

　　從以上兩個例子中，我們可以看出，雖然檢視是對SQL語句的封裝，但是，兩者仍然有差異。建立檢視的查詢語句必須要遵守一定的限制。如要保證檢視的各個列名的唯一;如果自阿檢視中某一列是一個算術表示式、函式或者常數的時候，要給其取名字，等等。

　　限制條件四：許可權上的雙重限制

　　為了保障基礎表資料的安全性，在檢視建立的時候，其許可權控制比較嚴格。

　　一方面，若使用者需要建立檢視，則必須要有資料庫檢視建立的許可權。這是檢視建立時必須遵循的一個基本條件。如有些資料庫管理員雖然具有表的建立、修改許可權;但是，這並不表示這個資料庫管理員就有建立檢視的許可權。恰恰相反，在大型資料庫設計中，往往會對資料庫管理員進行分工。建立基礎表的就只管建立基礎表;負責建立檢視的就只有建立檢視的許可權。

　　其次，在具有建立檢視許可權的同時，使用者還必須具有訪問對應表的許可權。如某個資料庫管理員，已經有了建立檢視的許可權。此時，若其需要建立一張員工工資資訊的檢視，還不一定會成功。這還要這個資料庫管理員有美譽跟工資資訊相關的基礎表的訪問許可權。如建立員工工資資訊這張檢視一共涉及到五張表，則這個資料庫管理員就需要擁有者每張表的查詢許可權。若沒有的話，則建立這張檢視就會以失敗告終。

　　第三，就是檢視許可權的繼承問題。如上面的例子中，這個資料庫管理員不是基礎表的所有者。但是經過所有者的授權，他就可以對這個基礎表進行訪問，就可以以此為基礎建立檢視。但是，這個資料庫管理員有沒有把對這個基礎表的訪問許可權再授權給其他人呢?如他能否授權給A使用者訪問員工考勤資訊表呢?答案是不一定。預設情況下，資料庫管理員不能夠再對其他使用者進行授權。但是，若基礎表的所有者，把這個權利給了資料庫管理員之後，則他就可以對使用者進行重新授權。讓資料庫管理員可以給A使用者進行授權，讓其可以進行相關的操作。

　　可見，檢視雖然靈活，安全，方便，但是其仍然有比較多的限制條件。根據筆者的經驗，一般在報表、表單等等工作上，採用檢視會更加的合理。因為其 SQL語句可以重複使用。而在基礎表更新上，包括紀錄的更改、刪除或者插入上，往往是直接對基礎表進行更新。對於一些表的約束，可以通過觸發器、規則等等來實現;甚至可以通過前臺SQL語句直接實現約束。作為資料庫管理員，要有這個能力，能夠判斷在什麼時候使用檢視，什麼時候直接呼叫基礎表。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16436858/viewspace-566614/，如需轉載，請註明出處，否則將追究法律責任。