許多關(guān)系數(shù)據(jù)庫引擎支持視圖。視圖可以充當(dāng)一種虛擬表，并且使用它們有時可以極大地改善體系結(jié)構(gòu)和系統(tǒng)的可測試性，但是當(dāng)然可能要付出一定的代價。

常見的簡單計算

當(dāng)您要在系統(tǒng)其余部分中使用的表包含可能保留的數(shù)據(jù)時，可能會遇到這種情況，該數(shù)據(jù)不適合直接用于特定目的的消耗。

例如，在復(fù)式記帳系統(tǒng)中，總帳表可能會將預(yù)訂金額保留為所有行中的正十進(jìn)制數(shù)字，而金額的符號實際上是由保留了條目的貸方或借方的其他列確定的。

正是這樣的事實，即預(yù)訂值是以這樣的拆分方式編碼的，并且出于許多用途的目的，實際值需要在預(yù)訂端的上下文中進(jìn)行，因此需要做出一個簡單的計算表達(dá)式，該表達(dá)式將應(yīng)用于預(yù)訂的每一行。基礎(chǔ)表。包含基于金額和貸方或借方的新計算值的簡單視圖可能是理想的選擇。曾經(jīng)寫過，后來在許多地方使用?？梢韵胂螅@里要付出的代價就是性能。數(shù)據(jù)庫引擎需要對通過此視圖檢索的每一行應(yīng)用所述計算，但是同樣，這是對行本地數(shù)據(jù)執(zhí)行的簡單的符號更改表達(dá)式。

數(shù)據(jù)的簡潔版本

表通?？梢园S多列，這些列用作行中描述的項目的屬性。數(shù)據(jù)的特定用法不一定總是需要所有這些列。視圖可以在這里幫助選擇僅特定使用場景和首選列順序所需的列。

從寬表檢查數(shù)據(jù)時，很難清楚地了解其中的內(nèi)容。如果表中有一百列，而您唯一需要的列是位置1、89、16和74的列，并且您希望它們按該順序排列，因為它們最重要，再加上一些簡單的計算列和其他幾列都不是那么重要非常重要，但對于這種情況仍然有用。

我更喜歡這樣寫視圖-首先將重要的列（或計算的表達(dá)式）并按順序排列好，然后再添加一些有用但非必要的列，僅此而已。

也有警告。例如，您正在使用SQL Server并創(chuàng)建一個沒有SchemaBinding屬性的視圖。在更改基礎(chǔ)表的定義之前，一切工作正常，例如在該表的列列表中間插入新列。突然，您的視圖開始輸出一些奇怪的數(shù)據(jù)，例如“先生”?；颉疤?在fist_name列中。創(chuàng)建視圖時，引擎實際上使用視圖的元數(shù)據(jù)保存該視圖的元數(shù)據(jù)，該視圖的訪問列由該列的索引而不是該列的名稱引用。某些隨后的表修改以后可能會導(dǎo)致此問題。您可以通過應(yīng)用SchemaBinding屬性來保護(hù)自己免受這種情況的影響，但是，當(dāng)真正需要更改基礎(chǔ)表時，也會導(dǎo)致管理問題，因為它迫使您在修改表之前刪除整個架構(gòu)綁定視圖集，并在以后重新創(chuàng)建它們（如果依賴于另一個）。使用該屬性的其他限制也適用。但是話又說回來，通過在列列表的中間插入列來修改表并不是輕量級的操作，應(yīng)該很少發(fā)生。我寧愿不使用SchemaBinding屬性，而使用腳本通過使用系統(tǒng)過程sp_refreshview自動刷新所有視圖的內(nèi)部元數(shù)據(jù)定義。也可能有一些警告：如果有人重命名，則某些版本的SQL Server可能會將視圖定義還原為舊版本。也不適用于Azure云服務(wù)器版本。

組織代碼

SQL Server引擎支持?jǐn)?shù)據(jù)庫中的架構(gòu)作為邏輯單元，可以幫助組織對象和應(yīng)用安全性。當(dāng)我使用一個陌生的數(shù)據(jù)庫并擁有創(chuàng)建新內(nèi)容的權(quán)限時，我通常通常先創(chuàng)建“幫助”架構(gòu)，然后開始在其中創(chuàng)建助手視圖和其他對象。這背后的原理很簡單–檢查數(shù)據(jù)庫模型需要花費時間，并且在您學(xué)習(xí)模型的各個部分時，將有趣的查詢包裝到視圖中以幫助您更快地瀏覽數(shù)據(jù)并可能暴露模型中的某些異常要容易得多。或其中的數(shù)據(jù)。

想法還在于，這些幫助程序視圖實際上只是–它們未在系統(tǒng)的其他部分中使用，并且沒有任何依賴于它們的視圖。您可以在學(xué)習(xí)新事實時對其進(jìn)行編輯，或者如果發(fā)現(xiàn)它們無用，則可以將其完全刪除。在這種視圖中，您可以輕松地添加注釋，其中包含有關(guān)如何從研究中選擇有趣的案例的示例。當(dāng)您或您的同事在很久以后重新查看這種觀點并回想起為什么做某事的原因時，這可以使您記憶的速度更快。在您已經(jīng)連接到的特定數(shù)據(jù)庫的上下文中，無需搜索文件，即提供幫助。

使用視圖的另一個示例是在數(shù)據(jù)庫與調(diào)用客戶端API和應(yīng)用程序之間創(chuàng)建某種“接口”。這當(dāng)然不是必需的，但是隨著系統(tǒng)復(fù)雜性的增加，從數(shù)據(jù)庫的原始表中進(jìn)行抽象層將是有益的。您可以在“ api”或“ app”模式中放置視圖，并同意您的同事在應(yīng)用程序端使用這些模式。這種方法的一個好處是，無論是數(shù)據(jù)正確性還是檢索性能，任何特定視圖的可測試性都更加容易。隨著數(shù)據(jù)量的增長，您可以測試這種視圖的性能和執(zhí)行計劃，并可能發(fā)現(xiàn)需要添加或更改索引以幫助加快處理速度。

當(dāng)然，這種方法也可能會有弊端，因為您將不得不管理另一層抽象并使它與系統(tǒng)的其他部分保持同步。