我只是想了解在RDBMSes中使用哪些視圖的一般概念。也就是說，我知道一個觀點是什麼以及如何制定一個觀點。我也知道我以前用過他們的東西。什麼意見適合？
但我想確保我有一個什麼樣的看法是有用的一個透徹的瞭解，哪些視圖不應該是很有用的。更具體地講：
（並記錄在案，其中有些問題是故意天真。這部分是一個概念檢查。）
1）什麼是有用的視圖？
IOPO只在一個地方
•無論你考慮數據本身或引用連接表的查詢，利用視圖避免不必要的冗餘。
•視圖還提供了一個抽象層，防止直接訪問表（以及由此產生的引用物理依賴關係的手銬）。事實上，我認爲這是 好的做法 只提供抽象訪問您的底層數據（使用視圖和表值函數），包括視圖如
CREATE VIEW AS
SELECT * FROM tblData
我hafta承認有一個很好的在這個建議中，「按照我說的做，不按我做的」）
2）有什麼情況可以在你不應該使用視圖的時候使用視圖嗎？
性能視圖連接曾經是一個問題（例如SQL 2000）。我不是專家，但我一會兒不擔心。 （我也不能想到我目前正在使用視圖連接的位置。）
視圖可能過度殺傷的另一種情況是隻能從一個調用位置引用視圖，而可以使用派生表。就像匿名類型優於.NET中的類一樣，如果匿名類型只被使用/引用一次。
•見派生表描述 http://msdn.microsoft.com/en-us/library/ms177634.aspx
3）你爲什麼要代替使用的東西視象表值函數，反之亦然？
（除了性能原因）表值函數在功能上等同於參數化視圖。實際上，一個常見的簡單表值函數用例只是簡單地將WHERE子句過濾器添加到單個對象中已存在的視圖中。
4）有沒有任何情況下，視圖可能是有用的，乍一看並不明顯？
我想不出任何不明顯的用途。 （我想如果可以的話，那會使它們變得明顯;）
在某種程度上，一個觀點是一樣的接口。您可以根據需要更改基礎表結構，但該視圖爲代碼提供了一種無需更改的方法。
視圖是提供一些簡單的報告作家的一個很好的方式。如果您的業務用戶想要訪問Crystal Reports等數據，則可以在他們的帳戶中爲其提供一些簡化數據的視圖 - 甚至可以爲它們進行非規範化處理。
視圖可以被用於提供安全性（即：用戶可以訪問的觀點，僅訪問在一個表中的某些列），視圖可以爲更新，插入等提供額外的安全視圖還提供一種方法來別名柱名稱（與sp相似），但視圖更多地與實際表格隔離。
在某種意義上非規範化的意見。非規範化有時需要以更有意義的方式提供數據。無論如何，這是許多應用程序在其對象中通過域建模的方式。他們幫助以更貼近企業視角的方式呈現數據。
-1「views denormalize」？對不起，但這是無稽之談，除非它是合格的。 – 2010-03-04 17:20:51
他們絕對非規範化。如果你有相關的表格被歸一化爲第三個統一形式，並且你創建了一個'扁平化'這個關係的視圖，那麼這不是非規範化？ – Kilhoffer 2010-03-05 13:34:26
視圖可以集中或合併數據。我在哪裏我們在幾個不同的鏈接服務器上有許多不同的數據庫。每個數據庫保存不同應用程序的數據。這些數據庫中的一些數據庫保存了與許多不同應用程序相關的信息。在這些情況下，我們要做的是在應用程序的數據庫中創建一個視圖，從數據庫中真正存儲數據，以便我們編寫的查詢看起來不像跨越不同的數據庫。
除了其他人聲明的內容之外，視圖還可以用於從應用程序中刪除更多的複合SQL查詢。
作爲一個例子，而不是在應用程序操作的方式：
SQL = 「選擇A，B從表1工會 選擇A，B從表2」;
你可以抽象的，要一個觀點：
創建視圖union_table1_table2_v爲
選擇A，B從表1
工會
選擇A，B從表2
和在應用代碼中，只需要：
sql =「select a，b from union_table1_table2_v」;
此外，如果數據結構有變化，您將不必更改應用程序代碼，重新編譯和重新部署。你只需要改變數據庫中的視圖。
爲什麼我要在數據庫而不是應用程序中編寫複雜的sql？ – 2012-06-09 06:33:36
查詢越複雜，未來可能會發生更改，部分原因是由於它只會觸及更多表格。當數據庫結構發生變化時，您還必須更改代碼並進行發佈。如果在視圖中抽象出這種複雜性，則DBA可能能夠對下表進行結構更改，而無需更改代碼。 – CodingWithSpike 2012-06-11 03:02:33
OP詢問是否存在可能使用視圖的誘惑，但這不合適。
你不想使用視圖是複雜連接的替代。也就是說，不要讓你的程序編程習慣將問題分解成更小的部分，這會導致你使用多個視圖連接在一起而不是一個較大的連接。這樣做會殺死數據庫引擎的效率，因爲它本質上是在做幾個單獨的查詢而不是一個大的查詢。
例如，假設您必須將表A，B，C和D連接在一起。您可能會試圖從表格A & B以及從C & D以外的視圖中查看視圖，然後將這兩個視圖結合在一起。在一個查詢中加入A，B，C和D會好得多。
我不認爲這是正確的，至少這不是數據庫管理系統理論的方式（各種實現可能決定不遵守該理論）。查詢解析器將基本上用相應的sql替換它看到的任何視圖，並且優化器將從那裏開始。這兩個案例應該是相同的。 – SquareCog 2008-10-18 00:03:19
當您可以將索引添加到視圖時，這也不適用。 – therealhoff 2008-10-18 00:10:25
@Barry Brown：什麼產品展示這種愚蠢的行爲？ – 2010-03-04 17:26:39
答覆迄今是正確的 - 觀點有利於提供安全，非規範化（雖然有太多的痛苦下來，如果做錯了這條道路），數據模型抽象等
此外，意見普遍用於實現業務邏輯（失效用戶是在過去40天內未登錄的用戶，諸如此類）。
我想強調使用視圖進行報告。通常，在規範化數據庫表以提高性能（尤其是編輯和插入數據（OLTP使用））和反規範化以減少用於報告和分析（OLAP使用）的查詢的表連接數量之間存在衝突。必要時，OLTP通常會贏，因爲數據輸入必須具有最佳性能。然後創建視圖以獲得最佳報告性能，可以幫助滿足這兩類用戶（數據輸入和報告查看者）。
視圖隱藏了數據庫的複雜性。他們出於很多原因很有用，並且在很多情況下都很有用，但如果您有允許用戶編寫自己的查詢和報告的用戶，則可以將它們用作安全措施，以確保他們不會提交設計不當的問題查詢與令人討厭的笛卡爾聯接，取消您的數據庫服務器。
視圖可以在SQL腳本中保存大量重複的複雜JOIN語句。您可以在某個視圖中封裝一些複雜的JOIN，並在需要時在您的SELECT語句中調用它。這有時會比在每個查詢中寫出連接語句方便，直接和容易。
我記得一個很長的SELECT，它涉及幾個UNION。每個UNION都包含一個加入價格表的功能，這個功能是通過一個SELECT自己創建的，本身相當長且很難理解。我認爲創建價格表是一個好主意。它會將整個SELECT縮短一半左右。
我不知道數據庫是否會評估一次或每次調用一次。有人知道嗎？如果前者使用視圖會提高性能。
視圖只是一個存儲的命名SELECT語句。考慮像庫功能這樣的觀點。
無論何時您需要[my_interface]！= [user_interface]。
例子：
表A：
查看錶A：
這是一種方法，您可以隱藏來自客戶的id並將信息同時重命名爲更詳細的名稱。
該視圖將使用主鍵ID的基礎索引，因此您不會看到性能損失，只是選擇查詢的更好的抽象。
類似於此處發佈的問題：http://stackoverflow.com/questions/1278521/why-do-you-create-a-view-in-a-database – MedicineMan 2010-02-05 00:58:07