通過視圖來訪問數據其優點是非常明顯的如可以起到數據保密保證數據的邏輯獨立性簡化查詢操作等等
但是話說回來SQL Server數據庫中的視圖並不是萬能的他跟表這個基本對象還是有重大的區別在使用視圖的時候需要遵守四大限制
限制條件一視圖數據的更改
當用戶更新視圖中的數據時其實更改的是其對應的數據表的數據無論是對視圖中的數據進行更改還是在視圖中插入或者刪除數據都是類似的道理但是不是所有視圖都可以進行更改如下面的這些視圖在SQL Server數據庫中就不能夠直接對其內容進行更新否則系統會拒絕這種非法的操作
如在一個視圖中若采用Group By子句對視圖中的內容進行了匯總則用戶就不能夠對這張視圖進行更新這主要是因為采用Group By子句對查詢結果進行匯總在後視圖中就會丟失這條紀錄的物理存儲位置如此系統就無法找到需要更新的紀錄若用戶想要在視圖中更改數據則數據庫管理員就不能夠在視圖中添加這個Group BY分組語句
如不能夠使用Distinct關鍵字這個關鍵字的用途就是去除重復的紀錄如沒有添加這個關鍵字的時候視圖查詢出來的紀錄有條添加了這個關鍵字後數據庫就會剔除重復的紀錄只顯示不重復的條紀錄此時若用戶要改變其中一個數據則數據庫就不知道其到底需要更改哪條紀錄因為視圖中看起來只有一條紀錄而在基礎表中可能對有的紀錄有幾十條為此若在視圖中采用了Distinct關鍵字的話就無法對視圖中的內容進行更改
如果在視圖中有AVGMAX等函數則也不能夠對其進行更新如在一張視圖中其采用了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語句直接實現約束作為數據庫管理員要有這個能力能夠判斷在什麼時候使用視圖什麼時候直接調用基礎表
From:http://tw.wingwit.com/Article/program/SQLServer/201311/22451.html
