什么时候应该在SQL Server中使用XML数据类型？

什么时候应该在Microsoft SQL Server中使用XML数据类型？

我做了类似的事情，将对象数据序列化为XML进行存储。这消除了使用表，列和关系来保存复杂对象数据的负担。通过使用结果XML符合的架构可以帮助该过程，并且数据库表可以用于有关所讨论对象的元信息。就我而言，扩展数据库架构以适应对象布局将是一项艰巨的任务！

就个人而言，我以前从未在SQL Server中使用过XML字段类型，而且自从他们添加了此功能以来，我已经完成了很多数据库编程。在我看来，在本地使用XML内容总是存在程序和性能上的开销。老实说，我认为这是一个a头，因为在2000年代初期，每个人都在XML培训上。“哦，XML很热，所以让我们将其添加到SQL Server中，这样就不会显得过时了。”

我能看到的最好的业务案例可能是记录您收到的基于XML的数据消息，这些数据消息可能希望窥视它们的结构和数据，但出于业务或法律原因，希望保持原始消息的完整性。开销可能太大，无法将XML转换为表结构，但是在SQL Server中使用XML功能可能只会降低检查数据的成本，足以保证使用它。

可能还有许多其他原因使您想要使用它，但是坦率地说，除非您有非常具体的业务原因，否则在SQL Server中使用XML之前，您应该考虑其他通往幸福的途径。如果更有意义，请使用varchar（max）或文本字段。

当然只是我的意见 ：）

我只遇到过一些会积极追求在SQL Server中使用XML数据类型的方案。从最低到最有趣的顺序，这是我的脑海：

• 存储/归档其他应用程序生成的XML响应
  • 例如，我们使用应用程序集成框架（AIF）在自定义Silverlight应用程序和Dynamics AX之间进行通信。我们将入站和出站消息都存储在数据库中，以帮助解决这些应用程序之间的通信问题
  • 因为字段类型是XML而不是通用字符串类型（即VARCHAR），所以我们能够使用XQuery专门查询与某些特定条件匹配的消息。使用简单的字符串LIKE匹配将更加困难
• 缓存/持久编写响应消息
  • 使用触发器或应用程序代码更新XML字段，这将模仿计算列
  • 与其持续不断地基于调用应用程序重新生成XML响应，您只会在更新行时而不是在每次调用时才产生开销
  • 当SELECT的频率比UPDATE / INSERT的频率高得多时，这种方法效果最好。
• 在单个字段中存储多个值
  • 我见过的一种做法是使用XML数据类型在单个字段中存储值的集合
  • 好处是您不必为简单的键/值存储设计额外的表集
  • 不利的一面是数据未完全规范化，使得查询不那么明显
  • 但是，如上所述，您可以在该XML字段上使用XQuery来选择与标识条件匹配的行，从而部分抵消了未完全标准化的影响。

所有这些，在99％的时间内，设计架构时，我绝对不需要XML字段。

我见过几次SQL Server中的XML数据类型，它基本上已经像数据库中的其他字段一样被用作查询过的字段，如果您有大量数据，可能会对性能产生非常不利的影响。有一个原因叫它SQL服务器而不是XML服务器。:-)违反XML的查询根本不如进行常规选择查询那样快。

我可以看到它用于存储查询得很少的XML，例如将完整的XML文档存储为XML数据类型，但是将可搜索字段（关键字）与XML文档分开存储。这样，您可以更快地查询信息，并在到达要查看完整文档的位置时提取XML文档。实际上，我不得不回过头来使用一些应用程序来执行此操作，在这些应用程序中，人们试图将XML数据类型用作查询量很大的字段，并且数据已经增长到查询变得太慢的地步。

我主要将XML类型字段用于与ASMX Web服务或WCF服务相关的日志记录目的。您可以保存请求或响应消息。

在大多数情况下，您将XML保存在数据库中仅供参考-而不是用于常规业务活动（不是从代码中每5秒查询一次）。如果发现自己这样做，请确定通常查询或经常使用的字段，并为其创建单独的列。这样，当您将XML保存到数据库时，您可以提取这些字段并将其保存到其对应的列中。稍后，在检索它们时，您无需查询XML文档，只需使用为此目的创建的列即可。

考虑到需要哪些条件才能允许Sql Server中的Xml字段时，这些想法一时兴起，马上就想到了：

• 编码的二进制数据，可以在需要酸的地方进行交换，例如控制资源
• 使用动态信息将整体重构的文档片段
• 用户提交的您要隔离的文档或片段，至少在临时的基础上，请直接与文件系统隔离。

我在客户端-服务器应用程序中广泛使用XML，以便在一次调用数据库中保存结构化数据。以带明细行的发票为例。让客户将业务对象序列化为XML并在单个调用中传递给存储的proc很简单。proc决定是否需要插入或更新；它可以获取父发票ID（标识列）以分配给明细记录，所有这些都在服务器端事务内完成，而客户端不必进行多次往返。我不需要20个左右的参数来指定标题记录，也不必为每个发票行都调用。而且，通常可以进行模式更改或引入日志记录/审核，而无需接触客户端。