SQL Server視圖管理有什么限制條件

這篇文章主要介紹了SQL Server視圖管理有什么限制條件，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

　　限制條件一：視圖數(shù)據(jù)的更改

　　當用戶更新視圖中的數(shù)據(jù)時，其實更改的是其對應的數(shù)據(jù)表的數(shù)據(jù)。無論是對視圖中的數(shù)據(jù)進行更改，還是在視圖中插入或者刪除數(shù)據(jù)，都是類似的道理。但是，不是所有視圖都可以進行更改。如下面的這些視圖，在SQLServer數(shù)據(jù)庫中就不能夠直接對其內容進行更新，否則，系統(tǒng)會拒絕這種非法的操作。

　　如在一個視圖中，若采用GroupBy子句，對視圖中的內容進行了匯總。則用戶就不能夠對這張視圖進行更新。這主要是因為采用GroupBy子句對查詢結果進行匯總在后，視圖中就會丟失這條紀錄的物理存儲位置。如此，系統(tǒng)就無法找到需要更新的紀錄。若用戶想要在視圖中更改數(shù)據(jù)，則數(shù)據(jù)庫管理員就不能夠在視圖中添加這個GroupBY分組語句。

　　如不能夠使用Distinct關鍵字。這個關鍵字的用途就是去除重復的紀錄。如沒有添加這個關鍵字的時候，視圖查詢出來的紀錄有250條。添加了這個關鍵字后，數(shù)據(jù)庫就會剔除重復的紀錄，只顯示不重復的50條紀錄。此時，若用戶要改變其中一個數(shù)據(jù)，則數(shù)據(jù)庫就不知道其到底需要更改哪條紀錄。因為視圖中看起來只有一條紀錄，而在基礎表中可能對有的紀錄有幾十條。為此，若在視圖中采用了Distinct關鍵字的話，就無法對視圖中的內容進行更改。

　　假如在視圖中有AVG、MAX等函數(shù)，則也不能夠對其進行更新。如在一張視圖中，其采用了SUN函數(shù)來匯總員工的工資時，此時，就不能夠對這張表進行更新。這是數(shù)據(jù)庫為了保障數(shù)據(jù)一致性所添加的限制條件。

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

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

　　我們都知道，視圖其實就是一組查詢語句組成。或者說，視圖是封裝查詢語句的一個工具。在查詢語句中，我們可以通過一些關鍵字來格式化顯示的結果。如我們在平時工作中，經(jīng)常會需要把某張表中的數(shù)據(jù)跟另外一張表進行合并。此時，數(shù)據(jù)庫管理員就可以利用SelectInto語句來完成。先把數(shù)據(jù)從某個表中查詢出來，然后再添加到某個表中。

　　當經(jīng)常需要類似的操作時，我們是否可以把它制作成一張視圖。每次有需要的時候，只需要運行這個視圖即可，而不用每次都進行重新書寫SQL代碼。不過可惜的是，結果是否定的。在SQLServer數(shù)據(jù)庫的視圖中，是不能夠帶有Into關鍵字。假如要實現(xiàn)類似的功能，只有通過函數(shù)或者過程來實現(xiàn)。

　　另外，跟Oracle數(shù)據(jù)庫不同的是，在微軟的SQLServer數(shù)據(jù)庫中創(chuàng)建視圖的時候，還有一個額外的限制。就是不能夠在創(chuàng)建視圖的查詢語句中，使用orderby排序語句。這是一個很特殊的規(guī)定。一些Oracle的數(shù)據(jù)庫管理員，在使用SQLServer數(shù)據(jù)庫創(chuàng)建視圖的時候，經(jīng)常會犯類似的錯誤。他們就搞不明白，為什么Oracle數(shù)據(jù)庫中可行，但是在微軟的數(shù)據(jù)庫中則行不通呢這恐怕只有微軟數(shù)據(jù)庫產(chǎn)品的設計者才能夠回答的問題。總之大家要記住的就是，在SQLServer數(shù)據(jù)庫中，建立視圖時，查詢語句中不能夠包含OrderBy語句。

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

　　在表關聯(lián)查詢的時候，當不同表的列名相同時，只需要加上表的前綴即可。不需要對列另外進行命名。但是，在創(chuàng)建視圖時就會出現(xiàn)問題，數(shù)據(jù)庫會提示“duplicatecolumnname”的錯誤提示，警告用戶有重復的列名。有時候，用戶利用Select語句連接多個來自不同表的列，若擁有相同的名字，則這個語句仍然可以執(zhí)行。但是，若把它復制到創(chuàng)建視圖的窗口，創(chuàng)建視圖時，就會不成功。

　　查詢語句跟創(chuàng)建視圖的查詢語句還有很多類似的差異。如有時候，我們在查詢語句中，可能會比較頻繁的采用一些算術表達式;或者在查詢語句中使用函數(shù)等等。在查詢的時候，我們可以不給這個列“取名”。數(shù)據(jù)庫在查詢的時候，會自動給其命名。但是，在創(chuàng)建視圖時，數(shù)據(jù)庫系統(tǒng)就會給你出難題。系統(tǒng)會提醒你為列取別名。

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

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

　　為了保障基礎表數(shù)據(jù)的安全性，在視圖創(chuàng)建的時候，其權限控制比較嚴格。

　　一方面，若用戶需要創(chuàng)建視圖，則必須要有數(shù)據(jù)庫視圖創(chuàng)建的權限。這是視圖建立時必須遵循的一個基本條件。如有些數(shù)據(jù)庫管理員雖然具有表的創(chuàng)建、修改權限;但是，這并不表示這個數(shù)據(jù)庫管理員就有建立視圖的權限。恰恰相反，在大型數(shù)據(jù)庫設計中，往往會對數(shù)據(jù)庫管理員進行分工。建立基礎表的就只管建立基礎表;負責創(chuàng)建視圖的就只有創(chuàng)建視圖的權限。

　　其次，在具有創(chuàng)建視圖權限的同時，用戶還必須具有訪問對應表的權限。如某個數(shù)據(jù)庫管理員，已經(jīng)有了創(chuàng)建視圖的權限。此時，若其需要創(chuàng)建一張員工工資信息的視圖，還不一定會成功。這還要這個數(shù)據(jù)庫管理員有美譽跟工資信息相關的基礎表的訪問權限。如建立員工工資信息這張視圖一共涉及到五張表，則這個數(shù)據(jù)庫管理員就需要擁有者每張表的查詢權限。若沒有的話，則建立這張視圖就會以失敗告終。

　　第三，就是視圖權限的繼承問題。如上面的例子中，這個數(shù)據(jù)庫管理員不是基礎表的所有者。但是經(jīng)過所有者的授權，他就可以對這個基礎表進行訪問，就可以以此為基礎建立視圖。但是，這個數(shù)據(jù)庫管理員有沒有把對這個基礎表的訪問權限再授權給其他人呢如他能否授權給A用戶訪問員工考勤信息表呢答案是不一定。默認情況下，數(shù)據(jù)庫管理員不能夠再對其他用戶進行授權。但是，若基礎表的所有者，把這個權利給了數(shù)據(jù)庫管理員之后，則他就可以對用戶進行重新授權。讓數(shù)據(jù)庫管理員可以給A用戶進行授權，讓其可以進行相關的操作。

　　可見，視圖雖然靈活，安全，方便，但是其仍然有比較多的限制條件。根據(jù)筆者的經(jīng)驗，一般在報表、表單等等工作上，采用視圖會更加的合理。因為其SQL語句可以重復使用。而在基礎表更新上，包括紀錄的更改、刪除或者插入上，往往是直接對基礎表進行更新。對于一些表的約束，可以通過觸發(fā)器、規(guī)則等等來實現(xiàn);甚至可以通過前臺SQL語句直接實現(xiàn)約束。作為數(shù)據(jù)庫管理員，要有這個能力，能夠判斷在什么時候使用視圖，什么時候直接調用基礎表。

感謝你能夠認真閱讀完這篇文章，希望小編分享的“SQL Server視圖管理有什么限制條件”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業(yè)資訊頻道，更多相關知識等著你來學習!