在 SQL Server 2008 R2 中设计用于存储 XML 数据的表答案

【问题标题】：Designing table to store XML data in SQL Server 2008 R2在 SQL Server 2008 R2 中设计用于存储 XML 数据的表
【发布时间】：2013-08-06 21:39:35
【问题描述】：

我计划使用 SQL Server 为我的应用程序存储 XML BLOB。我正在为一个设计决策而苦苦挣扎，并正在寻找任何有此主题经验的人的指导或建议。

需要存储为 XML 的数据有大约 100 个简单数据点。它们可以很容易地分为每组可能有 20 个数据点。在未来版本的应用程序中，我们计划通过添加新数据点来扩大数据范围，其中一些数据点将是分层的（列表、字典等）。

我们预计不需要对 XML 数据执行查询。最多它们将是非常简单的查询，如果需要，我们可以将任何数据点提升到关系列。

我不确定是否应该只创建一个巨大的 XML BLOB 来保存所有这些数据，或者是否应该将其分解为多个 XML 列。在 SQL Server 2008 R2 中处理 XML 数据类型是否有任何最佳实践或指南可以帮助我做出最佳决策？这还重要吗？

编辑：我已经准备好使用 XML 作为数据类型，我正在尝试决定是应该使用一个大 BLOB 还是将其分解为多个 XML 列。

【问题讨论】：

你见过这个吗？ msdn.microsoft.com/en-us/library/hh403385.aspx
Mikael，我已经读过了。但是，我仍然不确定是将我的 xml 分解为多列还是只拥有一个巨大的 blob。我知道有 2GB 的大小限制，但是我不担心达到这个限制。我相信有一个关于 XML 粒度的部分触及了我的问题，但老实说，我已经阅读了很多遍，但我仍然不知道该走哪条路。
如果在逻辑上为 XML 设置一列是有意义的，那么您应该这样做。关于粒度的链接中提到的内容与将 XML 拆分对更新时锁定数据的较小部分的行的影响有关。使用更多列对锁定没有任何影响。该链接还提到了在更新部分 XML 时的优化，无论是在您使用 XML 索引时，还是在不使用 XML 索引时，在列上拆分应该不会更快更新。
针对较小块的查询会更快，但如果您以后需要对多个列进行查询（使用或），我的猜测是较小块的好处会丢失。您可以为查询性能做的最好的事情是使用 SQL Server 2012 SP1 中引入的选择性 XML 索引。

标签： sql-server xml

【解决方案1】：

是的，这很重要！当您在 SQL Server 中将大型 XML blob 存储为 XML 数据类型时，它不会存储为文本 blob - 它是“解析”和“标记化”并以比仅使用 @987654322 时更有效的方式存储@ 存储文本表示。

如果它真的看起来像 XML，闻起来像 XML，又像 XML，那么 一定要使用 XML 数据类型！

更新：如果您只打算将 XML 作为一个整体进行存储和检索 - 我认为将其分解成块没有任何好处。 SQL Server 中的XML 数据类型最多可以容纳2 GByte 的数据（就像varchar(max)），您不会看到存储（和检索）多个较小的XML 片段带来的任何性能提升。

【讨论】：

似乎问题不在于XML vs 字符串类型，而是一个巨大的XML vs 多个[较小的] XML
@DanLing：更新了我的回复——如果你只打算在一次操作中存储和检索整个 XML blob——没有很多小块......
谢谢马克。如果我必须对数据进行更新，这会改变事情吗？抱歉，我没有从一开始就提到这一点。
@DanLing：只要您通常一次更新整个 blob（只需用新版本替换它），那么不会，这对性能没有任何不利影响。如果您开始只替换较小的部分 - 那么这可能是一个问题

【解决方案2】：

如果该字段将用于存储应用程序有效负载并且应用程序可以正确处理版本控制或未来对结构的修改，那么我将使用 xml 字段。存储为 xml 的唯一缺点是查询可能比扁平化数据更耗时。如果您的应用程序将所有以 xml 形式传递的数据处理，那么这将成为一个较小的障碍。

【讨论】：

【解决方案3】：

是的。

推荐使用 nvarchar(MAX) 来存储 XML。因为，如果（不久的将来）您计划更改它，修改您的存储以保留 json（而不是 xml），那么为您保留 Json 将非常灵活。但是，如果您选择使用 XML 数据类型，那么只使用 XML 是很严格的。然而，正如 Mark 所提到的，如果它真的看起来像 XML，闻起来像 XML，又像 XML，那么肯定使用 XML 数据类型！如果您的业务用例要求一次插入和检索整个 XML，那么我认为将其分解成块对性能没有太大好处。

【讨论】：