問題
我常被問到如何把駐留在物理服務器/SQL 實例上的數據庫轉變為它們相應的應用程序名稱。在准備計劃好的服務器停機通知時，這種需要就產生了，但在我的組織內與IT經理或非技術人員溝通時，這也是有價值的。如果你不是數據庫管理員或特定數據庫的應用分析師，你通常會無視數據庫的命名規則，而這些數據庫支持著你每日依賴的應用程序。這就是為什麼當需要產生時在適當的位置上由元數據庫來提供轉化很重要。
專家解答
大部分數據庫管理員擁有某種形式的數據庫元數據庫，他們依賴其來跟蹤范圍很廣的Microsoft SQL Server環境。我利用連接的服務器和分布式數據庫訪問來建立一個已經在我的環境中使用了七年的元數據庫。它不是漂亮的，但它是功能性很強的。跟很多IT開發者和數據庫管理員一樣，即使它有自身的不足我還是為自己的創造感到驕傲。它很慢，不像它可以的那樣最新型，也不像它應該的那樣安全。
自從讀了2007年5月和6月Rodney Landrum在SQL Server雜志上發表的關於SQL Server集成服務(SSIS)和數據庫管理員知識庫(DBA Repositories)的文章，我知道是時候采取別人的解決方法了。這對於我的環境來說是完美的，而一些改動也是容易采納的。2008年2月，一篇後續文章在SQL Server雜志上發表，在這篇文章裡，Rodney更新了他的解決方法。我下載了代碼，在我的測試環境裡審核，並迅速把它納入產品中。當大家普遍地為這個解決方法所提供的而感到高興時，在它包中缺少的一方面是把數據庫關聯到應用程序的能力。通過在他的解決方法中增加兩張額外的表，我可以在我的“土生土長”元數據庫中增加應用程序元數據到我現在使用的SQL Server雜志的方法中。
增加到我數據庫中的應用元數據包括創建兩張表：dbo.Applications，專為存儲所有程序的應用名稱，而這些程序在我的環境中依賴於SQL Server數據庫，還有dbo.Database_Applications，它保存SQL 實例、數據庫和應用程序之間的關系。
Applications Table
CREATE TABLE [dbo].[Applications]
(
[AppID] [int] IDENTITY(154,1) NOT NULL,
[ApplicationName] [varchar](100) NOT NULL,
)
Database_Applications Table
CREATE TABLE [dbo].[Database_Applications]
(
[DB_AppID] [int] IDENTITY(1,1) NOT NULL,
[ServerName] [varchar](50) NOT NULL,
[DatabaseName] [varchar](100) NOT NULL,
[ApplicationName] [varchar](100) NULL
)
你可能注意到，我沒有規范化dbo.Database_Applications表。如果我規范化，我會只存儲兩個區域：一個與存儲我的應用元數據的表有關的外鍵，和一個與我的元數據庫相對應的外鍵。我有自己的原因：
我沒有處理大量的數據：我有大概800個數據庫，這些數據庫在我的環境裡發布80個實例。雖然這對於一個數據庫管理員來說是個很大的環境，但是它既不轉變成在我的元數據表裡的大量紀錄，也不轉變成數據庫的巨大字節。
不是通過dbo.Applications表的主鍵，而是包含表中的應用程序名，我可以通過只訪問dbo.Database_Applications表產生我的主要應用程序元數據報告(key Application Metadata report)。
我的環境中的SQL元數據庫使用“焦土政策”人口處理方法，除了SQL Agent Job History和Backup History，其他的表都被每天刪除和重新載入。我發現在
dbo.Database_Applications表中保存信息可以使我的生活變得很容易。
