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

Question

(这篇文章征求了有关存储 XML 的个人经验；请分享您所知道的。:-))

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

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

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

一些额外的背景:我使用了 'xsd.exe'相当于 XsdObjectgenerator基于 XML 模式创建 .net 类。当服务收到 XML 文件时，它被反序列化为 .net 类的一个实例。该实例用于执行服务的操作。我最初的计划是然后使用上面的选项 #1 来存储 XML。如果我需要更新或报告数据，我只需将数据库记录反序列化回我的 .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(以及大部分或全部)，那么你最好将它分解成关系部分来开始.