我有一个包含一些关系列和一个XML列的表，它有时会保存相当大的数据块。我还有一个使用数据库的简单web服务。我需要能够报告XML列中某个元素的所有实例，某个元素的所有不同值的列表，以及类似的事情。
我能够得到一个元素的所有不同值的列表，但没有比这更进一步。我最终编写了令人难以置信的复杂T-SQL代码来做一些在C＃中看起来非常简单的事情：遍历此表中的所有行，并将此（XPath | XQuery | XSLT）应用于XML列。我可以过滤关系列以减少数据量，但对于某些查询，这仍然是很多数据。
我的计划是在SQL Server中嵌入一个程序集（我使用的是2008 SP2）并让它为给定的查询动态创建一个索引视图（我还有其他逻辑来清理这个视图）。这将允许我保持网络流量，并可能允许我使用Excel和MSRS报告等工具作为廉价的用户界面，但我看到很多人说“只使用应用程序逻辑而不是SQL程序集” 。 （我猜，我可能会在这里完全咆哮错误的树）。
将大量数据抓取到Web服务并进行处理也会带来好处 - 我不太受SQL Server环境的限制（因为我不在其中）并且我的设置过程更容易。但这确实意味着我在网络上传输大量数据，在处理数据时将其存储在内存中，然后将其中的一部分丢弃。
欢迎任何建议。
由于
谢谢你们，你们一直都是一个很大的帮助。问题是我们在表中为一个文件生成一行，每个文件可能有多个结果，我们每次运行特定的构建作业时都会这样做。我想把它变成表格视图。
这个构建作业的每次执行检查了几个属性的数千个文件，在某些情况下，这些测试中的每一个都产生了数千个结果（MSIVAL测试是最糟糕的罪魁祸首）。
答案（呃！）是在进入数据库之前将其展平！根据您的反馈，我决定尝试为每个文件的每个测试为每个结果创建一行，并且XML只具有该结果的详细信息 - 这使得查询更加简单。当然，我们每次运行此工具时都会有数十万行，但性能要好得多。我现在有一个视图，它创建了构建作业发出的结果类之一的扁平版本 - 返回＆gt; 200,000并且需要＆lt; 5秒，相比之下，等效（复杂）查询大约需要3分钟我走了更平坦的路线，在10到30分钟之间进行旧（非数据库）版本的XML文件处理。
我现在连接的次数有些问题，但我知道如何解决这个问题。
再次感谢！ + 1全面
答案 0 :(得分：2)
我建议在TSQL中使用标准的xml工具。 （http://msdn.microsoft.com/en-us/library/ms189075.aspx）。如果您不想使用它，我建议在另一台机器上处理xml。 SQLCLR非常适合较小的功能，但是对于restrictions on the usable methods，一旦你尝试做更高级的事情，它往往会成为一种挫败感。
答案 1 :(得分：1)
你所询问的是一个巨大的平衡行为，它完全取决于几个因素。首先，数据库当前的负载是多少？如果您在已经负载很重的数据库上运行它，那么您可能希望在Web服务上执行此解析。 XML碎化和查询在SQL Server中是一个非常昂贵的过程，特别是如果您在没有为它们定义架构的未索引列上执行此操作。模式和索引有助于处理这种处理开销，但它们无法消除XML解析不便宜的事实。其次，您正在使用的数据量。完全有可能你只有太多的数据来推动网络。根据服务器的位置和数据量，您可能会遇到难以解决的问题。
最后，您机器的相关规格是什么？如果您的Web服务机器具有较低的内存，那么它将会破坏数据进出虚拟内存，试图解析XML会破坏您的性能。也许您没有运行功能最强大的数据库硬件，并且粉碎XML对于您在数据库计算机上运行的CPU而言性能过高。
在一天结束时，真正了解的唯一方法是尝试两种方式并找出对你有意义的方法。在Web服务机器上进行开发几乎无疑会更容易，因为LINQ to XML是一种更优雅的XML解析方式，而不是T-SQL中的XQuery。鉴于您在问题中提供的信息，我的指示是，从长远来看，T-SQL将为您带来更好的性能，因为您在数据库的每一行或至少大多数行上进行XML解析以进行报告。通过网络推送这种信息只是丑陋。也就是说，如果性能不是那么重要，那么可以说一下在应用服务器上进行所有解析的更简单，更易维护的路径。