微軟的SQL Server 數據庫管理員 ，快快想一下!在不使用任何的文檔的情況下，編寫一個查詢，從SQL Server 2000系統表中抽取索引的列表，然後列舉每個索引中的字段，並判斷這個字段是否按照升序或者降序進行排序。你有兩分鐘的時間。快!
如果你現在真的停下閱讀，開始用必不可少的兩分鐘時間思考這項不討好的任務，那麼現在你就陷入了一個大麻煩中，這裡面涉及了系統索引、系統索引關鍵字，系統字段，以及一些元數據函數，其中包括類似OBJECT_NAME 和INDEXKEY_PROPERTY這樣的備用信息。到現在為止，要編寫這樣的一個查詢很明顯要花費遠遠超過2分鐘的時間了。
不幸的SQL Server 2000數據庫管理員們，需要浏覽深奧的系統表，這是這項使用數據庫管理系統的工作中最糟糕的一部分。系統表，通常是有效率的，但是在我的印象裡，它可從來不是為了用戶友好設計的。
幸運的是，眼前就有了救星。在SQL Server 2005中，系統表不見了。是的。不見了。再也不需要對陌生的位進行操作，也不需要找出神秘的編碼方案——這在過去都是必需的。對於你們中間需要對遺留下來的參考這些表的人來說，我知道你在想什麼:無休止的機械的升級以保障與SQL Server 2005的兼容。但是還不要心生厭惡。系統中仍然存在類似系統表的對象，就是為了向下兼容的目的。但是表的自身是——或者是實際上應該是——被遺忘，像8-tracks 和 Tab一樣被投入了歷史的垃圾桶中。
那麼這些表去了哪裡呢?SQL Server 2005中的系統數據現在存儲在隱藏的“資源”表中，這個表只能被服務器自身直接訪問。低級用戶(和數據庫管理員)必須使用新的一系列的分類視圖，這些視圖顯示了從各種我們看不到也不能調用的隱藏表和各種隱藏函數中獲得的數據。以前版本的SQL Server 中的系統表現在作為一系列所謂的(也相當正確的)“兼容視圖”的形式實現。
分類視圖和它們的伙伴，動態管理視圖(下面進行解釋)，代表了一種處理元數據的方式，這些元數據是完全重新設計和重新思考出來的。沒有了那些只會給數據庫管理員一些底層數據的微小感覺的神秘的表，現在的SQL Server提供了豐富的資源:SQL Server 2005中有超過200個分類和管理視圖，取代了以前版本中大約50個的系統表。
所有這些視圖都可以在系統計劃中找到。(計劃是在SQL Server 2005中大大擴展了的安全特性。但是這是另一篇貼士的話題。)要看到可用視圖的完全列表，SQL Server Management Studio擴展了所有數據庫的系統視圖樹。或者通過T-SQL 從視圖自身選擇一個列表，並找出友好的易於理解的名字:
SELECT name
FROM sys.all_views
WHERE is_ms_shipped = 1
你還會發現再也不需要通過浏覽文檔來查找有關做某件關系系統數據的事情的線索。這些視圖都有很明確的自我解釋。
有關視圖名字的一些線索如下:那些前綴是dm_的是動態管理視圖，通過類似當前會話、鎖，以及系統資源的信息表示服務器的正在改變的狀態。其他的視圖都可以認為是分類視圖。那些前綴是all_的包含了有關系統對象(例如視圖)和用戶定義的對象的信息。那些沒有all_前綴的只包含了用戶定義的對象的信息。在那些包括了系統對象的視圖中，is_ms_shipping字段可用於區分用戶定義對象和系統對象。如果is_ms_shipped字段的值為1，則這一行代表了一個系統對象，否則，就是用戶定義的對象。
