相同或不同的表
XML 數據類型列可以在包含其他關系列的表中創建，也可以在與主表之間具有外鍵關系的獨立表中創建。
在滿足下列某個條件時，請在同一個表中創建 XML 數據類型列：
• 您的應用程序在 XML 列上執行數據檢索，並且不需要 XML 列上的 XML 索引。 或者
• 您需要在 XML 數據類型列上生成 XML 索引，並且主表的主鍵與其聚集鍵相同。有關詳細信息，請參閱將 XML 數據類型列編入索引一節。
在滿足下列條件時，請在單獨的表中創建 XML 數據類型列：
• 您需要在 XML 數據類型列上生成 XML 索引，但主表的主鍵與其聚集鍵不同，或者主表不具有主鍵，或者主表是一個堆（也就是說，沒有聚集鍵）。如果主表已經存在，則這可能是真的。
• 您不希望表掃描由於表中存在 XML 列（無論它是存儲在行中還是存儲在行外，都會占用空間）而降低速度。
XML 數據的粒度
XML 列中存儲的 XML 數據的粒度對於鎖定和更新特性而言至關重要。SQL Server 對 XML 和非 XML 數據采用了相同的鎖定機制。因此，行級鎖定會導致相應行中的所有 XML 實例被鎖定。當粒度比較大時，鎖定大型 XML 實例以便進行更新會導致多用戶場合下的吞吐量下降。另一方面，嚴重的分解會丟失對象封裝並提高重新組合成本。
對 XML 實例進行更新會將現有實例替換為更新後的實例，即使只修改單個屬性的值。XML 數據粒度越大，更新成本就越高。較小的 XML 實例會產生較高的更新性能。
對於良好的設計而言，重要的是保持數據建模需要與鎖定和更新特性之間的平衡。
非類型化、類型化和受約束的 XML 數據類型
SQL Server 2005 XML 數據類型實現了 ISO SQL-2003 標准 XML 數據類型。因此，它可以在非類型化 XML 列中存儲格式規范的 XML 1.0 文檔以及帶有文本節點和任意數量頂級元素的所謂的 XML 內容片段。系統將檢查數據的格式是否規范，不要求將列綁定到 XML 架構，並且拒絕在擴展意義上格式不規范的數據。對於非類型化 XML 變量和參數，也是如此。
如果您具有描述 XML 數據的 XML 架構，則可以將這些架構與 XML 列相關聯，以便產生類型化 XML。XML 架構用於對數據進行有效性驗證，在查詢和數據修改語句編譯過程中執行比非類型化 XML 更准確的類型檢查，以及優化存儲和查詢處理。
在下列條件下，請使用非類型化 XML 數據類型：
• 您沒有對應於 XML 數據的架構
• 您擁有架構，但不希望服務器對數據進行有效性驗證。當應用程序在服務器中存儲數據之前執行客戶端驗證時，或者暫時存儲根據架構無效的 XML 數據時，或者使用在服務器中不受支持的架構組件（例如 key/keyref）時，有時會出現這種情況。
在下列條件下，請使用類型化 XML 數據類型：
• 您擁有對應於 XML 數據的架構，並且希望服務器按照 XML 架構對 XML 數據進行有效性驗證。
• 您希望充分利用基於類型信息的存儲和查詢優化。
• 您希望在查詢的編譯過程中更充分地利用類型信息。
類型化 XML 列、參數和變量可以存儲 XML 文檔或內容 - 您在聲明時必須將它們指定為標志（分別指定為 DOCUMENT 或 CONTENT）。而且，您必須提供 XML 架構集合。如果每個 XML 實例恰好有一個頂級元素，請指定 DOCUMENT；否則，請使用 CONTENT。查詢編譯器在查詢編譯過程的類型檢查中使用 DOCUMENT 標記來推理唯一的頂級元素。
除了將 XML 列類型化以外，您還可以在類型化或非類型化 XML 數據類型列上使用關系（列或行）約束。在下列條件下，請使用約束：
• 無法在 XML 架構中表示業務規則。例如，花店的送貨地址必須在其營業地點周圍 50 英裡范圍之內，這可以編寫為 XML 列上的約束。該約束可能涉及到 XML 數據類型方法。
• 您的約束涉及到表中的其他 XML 列或非 XML 列。這方面的一個例子是：強制 XML 實例中存在的 Customer ID (/Customer/@CustId) 與關系 CustomerID 列中的值匹配。
文檔類型定義 (DTD)
XML 數據類型列、變量和參數可以使用 XML 架構而不是 DTD 加以類型化。然而，對於非類型化和類型化 XML，都可以使用內聯 DTD 來提供默認值，以便將實體引用替換為它們的擴展形式。
您可以使用第三方工具將 DTD 轉化為 XML 架構文檔，並且將 XML 架構加載到數據庫中。
