Microsoft SQL Server 2016最近在關系數據庫管理系統（RDBMS）中處于領先地位。 高性能，安全性，分析和云兼容性的結合使其成為領先的RDBMS 。 SQL Server 2017甚至支持R和Python編程語言，這進一步提高了它在學術機構中的數據科學家和數據專業人員中的吸引力。

這是一個激動人心的時刻的原因有很多是外本文的范圍，SQL Server開發，但要簡明概括他們：SQL Server已不僅成為頭號RDBMS，這也成為一個多 RDBMS。

牢記這些令人印象深刻的SQL Server新版本，您可能會想知道如何從預期對整體生產力產生最大影響的功能中獲得最大價值，尤其是在您缺乏經驗的情況下。 另一方面，如果您不參加每個網絡研討會，也不在瀏覽每篇有關新功能的文章，那么不必擔心太多。 許多公司仍在使用SQL Server 2008 R2，尤其是在金融和醫療保健等受到嚴格監管的行業中。

我會警告任何人，在不首先精通（如果不精通）基本技能之前，不要專注于SQL Server的任何新功能。

本文解釋了為什么元數據很有價值，什么是元數據，然后介紹了使用引用元數據的Transact-SQL（T-SQL）代碼解決的兩個實際問題。 從查詢目錄視圖到動態使用元數據，您應該不了解將減少您熟悉數據和獨立解決問題的時間和精力，從而使您的SQL Server開發技能更有價值的知識。

無論您使用的是哪個行業，公司或什至當前版本的SQL Server，您都可以學習這三個通用技能，這些技能可以高度移植，甚至可以跨越相對較大的軟件版本跳躍（例如，從SQL Server 2008 R2到2014）。 。

開發人員的三項基本SQL Server技能

SQL是您必須具備的首要技能，也是最顯而易見的技能。學習這種腳本語言的主要原因之一（除了它很有趣之外）還在于它的可傳遞性，即使在其他RDBMS之間也是如此。 當然，我說的是美國國家標準協會（ANSI）的標準SQL（SQL）語法，不一定是T-SQL，這是Microsoft的SQL方言。 就個人而言，我還發現學習SQL / T-SQL語法的新元素比適應圖形用戶界面上的新功能要容易。 出于本文的目的，我將基于以下假設來研究T-SQL：假定閱讀本文的人都是SQL Server開發人員的某種變體。

PowerShell是第二項技能。 PowerShell是另一種腳本語言，允許用戶自動執行各種有用的任務，這些任務通常涉及運行SQL Server Reporting Services報表，安排作業以及基本上完成許多數據庫管理員（DBA）的工作。 但是，使PowerShell更具吸引力的是它替代了使用.NET對象和方法的Windows DOS批處理語言（即，在命令提示符下使用的批處理語言）。 其價值的另一個原因是，與T-SQL不同，PowerShell可以自動化跨越Windows和SQL Server環境的任務。

除了這兩種豐富的腳本語言之外，還有第三種技能可以使任何精通SQL Server的用戶受益，這就是元數據的使用。 從技術上講，理解SQL Server元數據（就本文而言，除非明確指定，否則對“元數據”的所有引用都將意味著“ SQL Server”）是學習的主題，也是鍛煉和應用技能（即記憶關系和學習的機會） T-SQL）-本身并不是一項技能。 因此，每當我提到“元數據的使用”時，我的意思是“開發人員在T-SQL中應用元數據知識的程度。”

但是，我認為，元數據也是開發人員社區中最被忽視和低估的主題之一（而學習T-SQL顯然不是）。 許多入門的SQL Server或T-SQL書籍甚至都不會在以后的章節中討論它，即使有的話，甚至甚至很少。

熟悉SQL Server元數據是一項比大多數講師似乎更有價值的技能，特別是對于初學者而言，因為這是在SQL語言，數據庫設計以及物理和邏輯處理中將知識應用于理論概念的一種實用方法。

即使對于經驗豐富的開發人員和DBA，SQL Server元數據也可能非常有價值，因為它的實用性會隨著您在數據庫設計和編程的其他領域的創造力和能力而擴展。 在整篇文章中，我將提供一些T-SQL腳本的示例，這些示例會增加復雜性，并演示如何在嘗試解決問題時熟悉元數據會變得無價。

但是，在深入研究示例之前，我應該提出幾個重要的一般性觀點。 微軟的網站，通常稱為“在線圖書”（BOL），是我可以推薦的關于此主題的唯一最大資源。 實際上，您應該查看此頁面以熟悉各種類型的元數據，以及此頁面上的有關如何訪問元數據（即使用目錄視圖）的信息。

基本元數據查詢

查詢對象目錄視圖的簡單性和靈活性使即使是對SQL知識最少的用戶也可以很好地瀏覽數據庫中的對象和關系。 請允許我通過一個簡單的示例演示為什么元數據對開發人員有用。

對于那些感興趣的人，請注意，我正在使用SQL Server 2016 Express Edition和AdventureWorks2014示例數據庫（兩者都是完全免費的）。

假設您是虛構公司Adventure Works Cycles的新員工。 在查看了幾張表后，您會發現名為“ BusinessEntityId”的列出現了很多。 讓查詢在數據庫中顯示具有該名稱的每一列不是很好嗎？ 了解有關SQL Server元數據的基礎知識使之變得容易。

由于您知道[sys]。[all_objects]，[sys]。[schemas]和[sys]。[all_columns]，因此可以編寫一個簡單的查詢來實現BusinessEntityId的單個視圖。

use AdventureWorks2014 go select s.name as 'SchemaName',o.name as 'TableName',c.name as 'ColumnName' from sys.schemas as sinner join sys.all_objects as oon s.schema_id = o.schema_idinner join sys.all_columns as con c.object_id = o.object_id where c.name like 'BusinessEntityId' and o.type = 'U' order by SchemaName,TableName,ColumnName;

這是結果集：

元數據不僅僅用于編寫基本的臨時查詢。 考慮進行難以置信的復雜查詢的機會，以回答極其困難或耗時的問題。 例如，給定數據庫中存在多少個重復索引？ 它們是什么類型的索引？

不管您當前的T-SQL技能水平如何，尤其是通過目錄視圖和動態管理視圖（DMV）熟悉元數據都非常有價值。 這是一種有趣且易于訪問的機制，可以磨練您對T-SQL語言和公司主數據的了解，并隨著您在數據庫編程中不斷增強的能力而擴展。

現在，按照其余查詢中的注釋進行說明，這些注釋說明了使用元數據（結合一些業務知識）探索主數據如何可以幫助您獨立回答問題。

use AdventureWorks2014 goselect s.name as 'SchemaName',o.name as 'TableName',c.name as 'ColumnName' from sys.schemas as sinner join sys.all_objects as oon s.schema_id = o.schema_idinner join sys.all_columns as con c.object_id = o.object_id where c.name like 'BusinessEntityId' and o.type = 'U' order by SchemaName,TableName,ColumnName;--Now join two tables using BusinessEntityId select * from HumanResources.Employee as einner join Person.Person as pon e.BusinessEntityID = p.BusinessEntityID order by p.BusinessEntityID;--hmm, it looks like PersonType "EM" stands for "Employee," but what does "SP" mean? --let's see if there are any other PersonType values select distinct PersonType from HumanResources.Employee as einner join Person.Person as pon e.BusinessEntityID = p.BusinessEntityID order by p.BusinessEntityID;--apparently, there are none --run the previous query again and look for patterns --perhaps it has something to do with JobTitle? select distinct p.PersonType,e.JobTitle from HumanResources.Employee as einner join Person.Person as pon e.BusinessEntityID = p.BusinessEntityID order by p.BusinessEntityID;--looks like it could have something to do with all sales-related jobs

如果您了解有關SQL Server元數據的方法，則可以了解很多關于公司數據的信息。

元數據的高級應用

但是元數據的更高級應用又如何呢？ 如果您是在公司工作多年的經驗豐富的開發人員，該怎么辦？ 為什么要學習SQL Server元數據？ 好吧，一個更復雜的例子可能會讓您信服。

在Grant Fritchey在PASS本地用戶組活動中的演講之一中，他描述了有關如何提高SQL Server性能的10條技巧。 其中之一是尋找嵌套視圖并重寫它們（理想情況下是通過連接到表）。 所謂“嵌套”，是指創建視圖時引用其定義中的其他視圖。 給定視圖定義中嵌套的級別越多，性能下降的幅度越大。

顯而易見的解決方案是不編寫嵌套視圖，但這也不是避免其假設存在的借口，因為這樣做會限制性能調整的熟練程度，并依賴于將來不會成為問題的假設。 而且，如果您正在調查數據庫性能問題并且不確定嵌套視圖是否困擾數據庫，那么值得您花時間至少看看一下此問題是否是必須解決的問題。 。

但是，您如何去做呢？ 除了手動右鍵單擊對象資源管理器中的每個視圖并查看定義之外，為什么不創建一個利用動態SQL為您提供答案的元數據存儲過程？

我寫了兩個存儲過程，它們將在本文后面引用，以幫助您開始解決此問題。 碰巧有一個名為“ sys.dm_sql_referenced_entities”的系統函數，它接受兩個輸入參數：合格的視圖名稱（即“ schema.view”或“ [schema]。[view]”）和一個“引用類”。

就本文而言，只知道我們僅對數據庫對象感興趣，這意味著我們需要在第二個參數中使用字符串“ object”。 如果您想知道，如果使用其他引用類，則可以查看觸發器的引用。 有關更多信息，請參見此鏈接 。

既然我已經提到了“動態sql”，那么我應該解決兩類可能涉及的問題：安全性和性能。

動態SQL成本：安全性和性能

動態SQL本質上是“編寫SQL的SQL”。 盡管它在存儲過程中非常有用，但會帶來一些成本。 但是，在詳細說明這些成本之前，我必須指出，與嵌套視圖可能對數據庫產生的長期影響相比，它們可以忽略不計。

我很清楚，SQL注入是一種嚴重的安全風險，當開發人員編寫動態SQL時，這種風險就有可能發生。 對我來說幸運的是，“父”存儲過程不接受用戶輸入，也不打算在任何面向客戶的應用程序中使用。 更具體地說，動態SQL不會接受來自應用程序前端的用戶輸入來獲取其參數的值。

另一方面，如果您關心的是動態SQL的性能，那么我為您提供兩個答復：

首先，此“嵌套視圖”練習的目的是通過解決潛在的嚴重問題來提高數據庫的整體性能，而這種問題很少發生（也就是說，除非您有一群開發人員繼續定期嵌套視圖，在這種情況下，您會遇到更大的問題）。

由于問題（理論上）很少發生，因此您應該只希望不頻繁運行代碼，這意味著代碼性能不佳只會在您多次運行時才會引起關注。 換句話說，如果您專注于這些過程的性能卻以犧牲整個數據庫的性能為代價，則將完全失去問題的背景，因此，不要對代碼的性能考慮得太嚴格（但是如果可以，請隨時進行更多調整）。

其次，您可能還擔心由于動態SQL的非關系??性質，性能會受到影響。 我完全同意這樣一種觀點，即任何編寫SQL的人都應在可能的情況下盡力做到相關性（即，以符合集合論原理的方式進行編寫）。 不幸的是，沒有比該方法更符合關系模型的解決該問題的替代方法了。 如果您不同意，或者找到任何使我的代碼更具關系性的方法來改進我的代碼，請立即與我聯系。 我還應該提到，我已經寫了整篇文章 。

為了快速總結這些批評：與嵌套視圖可能對不斷增長的數據庫產生的長期和累積的，性能下降的影響相比，安全風險和性能問題可忽略不計。 該代碼本身可能并未針對可伸縮性和性能進行優化，但是如果使用得當，它將有助于您確保數據庫處于最佳狀態。

使您的元數據動態化

那么，動態SQL是否值得承擔這些風險？ 我能給您的最佳答案是，這取決于您要解決的問題的價值。 動態SQL是SQL開發人員工具帶中的另一種工具，它大大增加了解決問題的方式。 自動執行此嵌套視圖清除程序搜尋的第一步是使用sys.dm_sql_referenced_entities（為簡潔起見，我將使用“被引用實體”）編寫動態SQL語句，以返回所有被引用視圖的名稱和引用頻率：

[dbo]。[CountObjectReferences]

use [AdventureWorks2014] gocreate procedure [dbo].[CountObjectReferences] (@QualifiedView as varchar(255),@RefCount as int output ) as /******************************************************************************************************************* Author: Alex Fleming Create Date: 11-05-2017 This stored procedure accepts a string that contains a qualified view or table and returns the number of references. Examples of valid parameters: 'Sales.vStoreWithContacts' or '[Sales].[vStoreWithContacts]' *******************************************************************************************************************/ set nocount on; begindeclare @DynamicSQL varchar(3000) = ('select count(*)from sys.dm_sql_referenced_entities(' + '''' + @QualifiedView + '''' + ',''object'') as RefEntinner join sys.all_views as AllViewson RefEnt.referenced_id = AllViews.object_idwhere RefEnt.referenced_class = 1and RefEnt.referenced_minor_name is null;');exec (@DynamicSQL);end;/********************************Test********************************************* Note: AdventureWorks2014 does not contain any nested views out-of-the-box. Consequently, I have created several for testing. Here's the definition of two (one of them is nested by two levels):create view [HumanResources].[DuplicateEmployeeView] as ( select * from HumanResources.vEmployee ------standard view in AdventureWorks2014------ );create view [HumanResources].[DuplicateEmployeeView3] as ( select * from HumanResources.DuplicateEmployeeView );declare @RefCount int; exec dbo.CountObjectReferences @QualifiedView = 'HumanResources.DuplicateEmployeeView3', @RefCount = @RefCount output; *********************************************************************************/

[dbo]。[FindNestedViews_v3]

use AdventureWorks2014gocreate procedure dbo.FindNestedViews_v3 (@ViewRefCount as int output) as/*******************************************************************************************************************Author: Alex FlemingCreate Date: 11-05-2017This stored procedure finds all of the views in the current database, stores them in a temp table, then passes them as parameters into the dbo.GetViewReferences stored procedure and stores the results in a new temp table, which isthen queried for all views containing one or more views in their definitions.*******************************************************************************************************************/set nocount on;beginif object_id ('[tempdb]..[#SchemaViewTemp]') is not nulldrop table #SchemaViewTemp;create table #SchemaViewTemp( SVID int identity(1,1) NOT NULL primary key,SchemaViewString varchar(2000) NULL,RefCount int null); insert into #SchemaViewTemp (SchemaViewString)select s.name + '.' + v.name as 'SchemaViewString'from sys.all_views as vinner join sys.schemas as son v.schema_id = s.schema_idwhere v.object_id > 0order by SchemaViewString;if object_id ('[tempdb]..[#ViewReferences]') is not nulldrop table #ViewReferences;--this table stores the output of the insert/exec statement--(can't use the same table because there is no way of updating based on an exec statement)create table #ViewReferences( RefID int identity(1,1) not null primary key,RefCount int null); declare @UpdateStmt varchar(500);declare @cnt as int = 0;declare @ViewString as nvarchar(255);declare NestedViewReader cursor forselect SchemaViewStringfrom #SchemaViewTemp;open NestedViewReader;fetch next from NestedViewReaderinto @ViewStringwhile @@FETCH_STATUS = 0begininsert into #ViewReferences (RefCount)exec @ViewRefCount = dbo.CountObjectReferences@QualifiedView = @ViewString, @RefCount = @ViewRefCount output;set @UpdateStmt = ('update #SchemaViewTemp set RefCount = ' + cast((select RefCount from #ViewReferences where RefID = @cnt + 1) as varchar(3)) +' where SVID = 1 + ' + cast(@cnt as varchar(2)) + ';');print @UpdateStmt;--for troubleshootingexec (@UpdateStmt);set @cnt = @cnt + 1;fetch next from NestedViewReaderinto @ViewStringendclose NestedViewReader;deallocate NestedViewReader;drop table #ViewReferences;select *from #SchemaViewTemp where RefCount > 0order by RefCount desc;end;go/********************************Test***********************************declare @ViewRefCount as int;exec dbo.FindNestedViews_v3 @ViewRefCount = @ViewRefCount output;************************************************************************/

在動態SQL和游標之間，T-SQL的某些功能只是該解決方案不可避免的部分。 據我所知，使該想法起作用的唯一方法是使用動態SQL執行引用的實體系統功能。

此外，多次運行動態SQL的唯一方法是使用游標（除非您想嘗試使用擴展的存儲過程，但這不在本文的討論范圍之內）。 除了動態SQL和游標之外，您還有一些重要的設計決策。

一旦您有一個執行在數據庫，模式和視圖名稱中傳遞的動態SQL語句的存儲過程，您可能希望放慢速度并考慮設計，特別是通過回答設計問題：“我是否要中斷？將此存儲到另一個存儲過程中并調用它，還是將所有邏輯封裝在一個巨型存儲過程中？”

我將動態SQL包含在一個單獨的存儲過程中，而不是將其作為一個龐大的存儲過程的第一部分，這一事實是我的故意設計決定。 當時，我認為閱讀和維護起來會更容易。 此外，我想確保動態SQL的執行計劃是一致的（存儲過程的優點之一是防止優化器偶爾生成不同的執行計劃）。 我還發現編寫和測試更加容易。

確定如何存儲合格的視圖，將它們傳遞給[dbo]。[CountObjectReferences]存儲過程，存儲游標的結果，然后顯示最終輸出，這是此問題中比較困難的部分之一。 我們可以使用表變量，臨時表，用戶定義的表或視圖。

如果您在此存儲過程中使用嵌套視圖，那將有多諷刺？ 從技術上講，只有當您在其中編寫存儲過程的數據庫中沒有除過程中的嵌套視圖之外的嵌套視圖，這才具有諷刺意味。 現在很諷刺！

我之所以選擇臨時表，是因為我對表變量不太熟悉。 我不想在此過程中維護用戶定義的表，也沒有安全方面的顧慮阻止我直接訪問數據（因此排除了視圖）。 稍后添加索引以及輕松地在本地和全局之間更改臨時表的范圍的能力也是吸引我的最初決定的吸引人的特征。

從一開始我就沒有澄清過我是否想要一個更詳細的結果集（它為用戶提供盡可能多的相關元數據）還是包含最少的數據量以換取更高的性能，可維護性和簡便性。

在考慮了原始問題并認為我希望能夠臨時運行這些存儲過程之后，后者成為我的偏愛。我只需要一個簡單的結果集即可找到嵌套視圖。 基本上，您希望返回盡可能少的信息來回答您的問題。 在我們的例子中，這意味著返回所有包含其他視圖的視圖名稱，理想情況下，返回原始視圖和表之間存在多少級嵌套視圖。

在繼續之前，我必須指出，我知道使用游標會限制這種方法的可擴展性。 另一方面，在數據庫中嵌套視圖也不是完全可擴展的數據庫設計方法，因此也請記住這一點。

如果我不了解[sys]。[views]或引用的實體功能，這些存儲過程將是不可能的。 實際上，我最初是在[sys]。[schemas]和[sys]。[all_columns]上加入了[sys]。[all_objects]，它們的性能比本文引用的版本差。 指出元數據特權和動態SQL背后的安全性問題也很重要。

由于安全策略根據組織的規模和行業的不同而不同，因此，每當從事涉及SQL Server開發的工作時，都應使用這些因素使您的期望與要使用的DBA保持一致。 有關SQL Server元數據安全性的更多信息，請參閱Kalen Delaney的本文 。 實際上，我還建議您從Delaney中閱讀有關SQL Server元數據的更多信息。

其次，元數據訪問需要您的DBA的批準。 雖然允許任何用戶訪問系統元數據都存在很小的安全風險，但這實際上取決于您的DBA或公司對開發人員的信任程度。 除非您在受到嚴格監管的行業工作，否則這對您來說不太可能成為問題。

當使用術語元數據時，我特別專注于系統元數據。 我還應該指出DMV的用處，因為它們在DBA中得到了廣泛的使用和依賴，并建議任何開發人員都應該熟悉上述所有信息。

我發現最具挑戰性的是快速找到正確的DMV或系統元數據-當我從上一段中得出自己的建議時，這個問題肯定會減少。 關于這一點，我鼓勵遇到相同問題的任何人使用我的第一個示例，然后根據您要查找的內容對其進行修改（即，對其進行修改以根據關鍵字搜索來查找感興趣的DMV或系統視圖）。

通過額外的實踐，在沒有第三方軟件任何幫助的情況下，通過最大限度地提高您在SQL Server中解決問題的能力，元數據和DMV對您來說將變得無比寶貴。 更好的是，您大部分依賴SQL Server元數據的代碼仍將在Microsoft Azure中運行，從而使元數據的應用成為一種更具可移植性的技能。

考慮到技術興衰的混亂，可轉讓技能越來越難以識別和依賴，這使開發人員的生活（有時）變得不必要地困難。 因此，SQL Server元數據的價值證明了Microsoft對用戶授權的奉獻精神，這無疑表明了他們與開發人員一起為您創建產品的跡象。

翻譯自: https://www.javacodegeeks.com/2018/02/microsoft-sql-server-metadata-developers.html

總結

以上是生活随笔為你收集整理的针对开发人员的Microsoft SQL Server元数据的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。