虽然SQL Server支持XML但并不意味着在任何情况下XML都是最合适的选择。这让我想起了那些相信他们能够在多个SQL Server实例之间利用XML进行数据传递的架构师们。他们把一组相互关联的关系数据，采用XML进行分列存储，利用c#服务程序来选择数据，并将数据传递给准备接收的SQL Server实例。在接收端再对其进行分解，然后采用跟原系统同样的格式进行存储。

　　采用这种方式，主要的问题是在解析XML的时候会增加原系统服务器的CPU/RAM资源开销;还会因为XML的文本特性而增加网络带宽的占用;而且由于在接收服务器端分解XML也一样会给接收服务器带来附加的CPU/RAM开销。

　　我们需要紧记使用XML的目的：采用同一种数据格式在不同类型的系统之间传递数据。不可避免的，XML与生俱来的就具有一些缺点，例如：附加的标记名称会使数据量变大，而且还会因为对XML的切割和分析而增大对CPU/RAM的资源占用;由于XML是基于文档格式的，也就意味着对于那些小数据类型的数据，比如整型，在作为XML进行数据传送的时候，会被转化成文本类型再加上它们的标记名称，需要占用的空间从而立刻变大。

　　过去，已经被使用的XML的优点之一，集成数据块(例如，一连串的行数据)，分解数据，然后处理数据将其存储在相关格式当中。在SQL Server 2008之前，没有使用XML，那么就要多次连续地调用相关存储过程来反复执行。从SQL Server 2008开始，SQL Server 支持table-valued类型的参数传递。table-valued参数没有与 XML相关的开销，很大程度的减小了CPU/RAM的资源和网络带宽的占用。

　　由于CPU/RAM的负载瓶颈，在剖析和分解XML然后添加到SQL Server时，也同样关系到可测量性的问题。如果SQL Server正处于高负荷运行(或者是准备处于高负荷运行)，那么有一件事情必须要引起注意，就是预期分解的容积不要超过CPU/RAM所能负担的能力。当SQL Server处于高负荷运行而且XML分解还需要占用大量的负载，有一个更好的方法是将处理分解的操作分发到多个服务器上去运行各自运行自定义的写服务，将会在SQL Server上分解XML和调用存储过程来处理关系数据结果。系统在超负荷运行状态下，通常测量多个服务器的服务会比单个SQL Server更容易一些。