确定是将 XML 数据存储为 XML 还是规范化表

Question

（这篇文章是在征求个人关于存储 XML 的经验；请分享你所知道的。:-)）

我正在开发一个使用 XML 与外部服务通信的服务应用程序。我打算使用 SQL Server 2008 来存储接收并发送到外部服务的 XML。我正在探索将 XML 存储在数据库中的选项。我确定的三个选项是：

1. 将 XML 存储在 XML 数据类型列中
2. 创建表以存储 XML 中表示的各种父子关系。
3. 上述两种方法的混合，其中原始 XML 存储在 XML 数据类型列中，但 XML 中的几个字段分解为它们自己的列以简化查询和索引。

根据您的个人经验，我正在寻找有关在 SQL Server 中存储和检索 XML 数据的任何建议。

一些额外的背景知识：我使用了一个名为XsdObjectgenerator 的'xsd.exe' 等效项来创建基于XML 模式的.net 类。当服务接收到 XML 文件时，将其反序列化为 .net 类的实例。该实例用于执行服务的操作。我最初的计划是使用上面的选项 #1 来存储 XML。如果我需要更新或报告数据，我只需将 db 记录反序列化回我的 .net 类之一。

虽然这种方法有效并且使使用 xml 变得非常简单，但我担心随着数据量的增加，查询 XML 数据类型记录的性能会下降。这就是我探索上述选项 2. 和 3. 的原因。

除了存储 XML 之外，还将查询 XML 以便在报告和单独的 Web 应用程序中使用。数据库记录将被最终用户查询、排序、过滤、分组、汇总并可能更新。

Answer 1

我想这取决于您想在数据库中使用 XML 做什么。

如果您主要只是存储它，并且可能稍后将其作为一个整体检索并再次发送出去，那么我肯定会使用 XML 数据类型 - 将其分解成碎片是没有意义的。

但是，如果您主要需要处理 XML 文件的内容，并且可能还需要操作和更改该内容，那么建议创建带有列以匹配您的 XML 内容的表，并在存储时将其切碎，使用它，并在需要时使用SELECT (columns) FROM dbo.Table FOR XML..... 之类的东西从关系部分重新组装它

切碎和重新组装会产生开销 - 所以你需要问问自己这是否值得。但是，如果您需要过多地操作 XML 列，也会产生开销。

如果您只需要对 XML 中的一些属性进行只读访问，我已经开始欣赏将这些属性包装到 UDF 中并将其作为计算列显示在表中的能力。这样，您可以根据存储在 XML 中某处的值轻松地从表中选择某些内容 - 非常方便！但是不要过度使用这种方法——对于 2、3 个属性来说效果很好——但是如果你需要一遍又一遍地访问你的 XML（以及大部分或全部），那么你最好把它分解成关系片段开始.

Answer 2

在继续探索解决方案的同时，一位同事转发了以下适用链接：

• SQL Server Performance with Key/Pair Table vs XML Field and XPath
• XML Support in Microsoft SQL Server 2005

这些文章和其他研究的一些初步结论：

• 在 SQL Server 中使用 xml 数据类型时 灵活，查询大量数据将 慢一点，因为您实际上是在查询 blob 数据类型。
• 虽然您可以在 Sql Server 中为 xml 数据类型列创建索引，但该索引是在整个列上而不是在特定元素或属性上，因此索引不如非 xml db 列上的索引有效。
• 将 xml 以原始形式存储在 xml 中 数据类型字段，同时还维护 数据的解析版本 关系表或 非规范化平面表 查询和报告开始 成为最灵活的 解决方案。 xml 可以“切碎” 在查询表中 运行时或事后由 单独的服务或线程。

我将使用测试数据模拟每个解决方案并执行一些基准测试。一旦结果可用，我将在此处发布结果。

Answer 3

在一些工作（SQL 2000）之前，我们将 XML 存储为 TEXT 数据，我们的数据库变得非常臃肿——与其说是数据，不如说是用于识别它的标签。我做了一些测试，然后 pkzip（我确实说过这是几个工作之前）将所有数据压缩到原始大小的 3%。

建议 #1：确定您需要存储数据多长时间，以及是否/在可能的情况下归档旧数据。

建议 2：如果您使用的是 SQL 2008，请查看 XML 列的数据压缩选项。

（如果您的 XML 很短，可能不相关，但我们的都是 kbs 和 10kbs。）