3

我有一个包含一些关系列和一个 XML 列的表，其中有时包含相当大的数据块。我还有一个使用数据库的简单网络服务。我需要能够报告诸如 XML 列中某个元素的所有实例、某个元素的所有不同值的列表之类的事情。

我能够得到一个元素的所有不同值的列表，但没有比这更进一步。我最终编写了极其复杂的 T-SQL 代码来执行在 C# 中看起来非常简单的事情：遍历此表中的所有行，并将其 ( XPath | XQuery | XSLT ) 应用于 XML 列。我可以过滤关系列以减少数据量，但这对于某些查询来说仍然是很多数据。

我的计划是在 SQL Server 中嵌入一个程序集（我使用的是 2008 SP2）并让它为给定的查询动态创建一个索引视图（我有其他逻辑来清理这个视图）。这将使我能够降低网络流量，并且可能还允许我使用 Excel 和 MSRS 报告等工具作为廉价的用户界面，但我看到很多人说“只使用应用程序逻辑而不是 SQL 程序集” . （我想我可能在这里完全叫错了树）。

将大量数据抓取到 Web 服务并在那里进行处理也会有好处——我不受 SQL Server 环境的限制（因为我不住在其中），而且我的设置过程更容易。但这确实意味着我要通过网络传输大量数据，在处理数据时将其存储在内存中，然后将其中的一部分丢弃。

这里的任何建议将不胜感激。

谢谢

编辑：

谢谢大家，你们都帮了大忙。问题是我们在表中为一个文件生成一行，每个文件可能有多个结果，我们每次运行特定的构建作业时都会这样做。我想把它展平成一个表格视图。

此构建作业的每次执行都会检查数千个文件的多个属性，并且在某些情况下，这些测试中的每一个都会产生数千个结果（MSIVAL 测试是最严重的罪魁祸首）。

答案（呃！）是在它进入数据库之前把它弄平！根据您的反馈，我决定尝试为每个文件的每个测试的每个结果创建一行，而 XML 仅包含该结果的详细信息 - 这使得查询更加简单。当然，我们现在每次运行此工具时都有数十万行，但性能要好得多。我现在有一个视图，它创建了构建作业发出的一类结果的扁平化版本 - 这将返回 >200,000 并且需要 <5 秒，而我去之前的等效（复杂）查询大约需要 3 分钟更平坦的路线，旧（非数据库）版本的 XML 文件处理需要 10 到 30 分钟。

我现在对连接的次数有一些问题，但我知道如何解决这个问题。

再次感谢！全方位+1

4

2 回答 2

2

我建议在 TSQL 中使用标准的 xml 工具。（http://msdn.microsoft.com/en-us/library/ms189075.aspx）。如果您不想使用它，我建议您在另一台机器上处理 xml。SQLCLR 非常适合较小的函数，但是由于对可用方法的限制，一旦您尝试做更高级的事情，它往往会成为一种沮丧的练习。

于 2011-05-26T19:58:12.530 回答
1

你所问的实际上是一个巨大的平衡行为，它完全取决于几个因素。首先，您的数据库上的当前负载是多少？如果您在已经承受重负载的数据库上运行此程序，您可能希望在 Web 服务上进行此解析。XML 粉碎和查询在 SQL Server 中是一个非常昂贵的过程，尤其是当您在没有为它们定义架构的未索引列上执行此操作时。模式和索引有助于解决这种处理开销，但它们无法消除 XML 解析并不便宜的事实。其次，您正在使用的数据量。您完全有可能通过网络推送太多数据。根据服务器的位置和数据量，

最后，您的机器的相关规格是什么？如果您的 Web 服务机器内存不足，它将在虚拟内存中输入和输出数据，试图解析 XML，这会破坏您的性能。也许您没有运行最强大的数据库硬件，而分解 XML 的性能对于您的数据库机器上的 CPU 来说会令人望而却步。

归根结底，真正了解的唯一方法是尝试两种方法并找出对您有意义的方法。毫无疑问，在您的 Web 服务机器上进行开发会更容易，因为 LINQ to XML 是一种比 XQuery 硬塞进 T-SQL 更优雅的解析 XML 的方式。鉴于您在问题中提供的信息，我的指示是，从长远来看，T-SQL 将为您提供更好的性能，因为您正在对数据库中的每一行或至少大多数行进行 XML 解析以用于报告目的。通过网络推送这种信息实在是太丑陋了。也就是说，如果性能不是那么重要，那么在应用程序服务器上进行所有解析的更容易和更可维护的路线是有话要说的。

于 2011-05-26T20:56:41.657 回答