我已经看到一些关于这个主题的问题，但我正在寻找关于这两种技术之间性能差异的一些见解。
例如，假设我正在记录事件日志，这些事件将与特定事件的键/值对字典集一起进入系统。我将使用基础数据在事件表中记录一个条目，但随后我还需要一种方法来链接其他键/值数据。我永远不知道会出现什么类型的键或值，因此任何类型的预定义枚举表似乎都是不可能的。
此事件数据将不断流入，因此插入时间与查询时间一样重要。
当我查询特定事件时，我将使用事件中的一些字段以及键/值数据中的数据。对于 XML 方式，我将简单地使用 Attributes.exists('xpath') 语句作为 where 子句的一部分来过滤记录。
规范化的方法是使用一个表，其中基本上包含键和值字段，并带有指向事件记录的外部链接。这看起来干净简单，但我担心涉及的数据量。
最佳答案
“灵活”存储机制有三个主要选项。
XML 字段很灵活，但将您置于查询速度较慢的 blob 存储领域。当它使用 Xpath 查询从 blob 中挖掘内容时，我已经看到针对 30,000 行的小数据集的查询需要 5 分钟。这是迄今为止最慢的选项，但它很灵活。
键/值对要快得多，尤其是当您在事件键上放置聚集索引时。这意味着单个事件的所有属性将一起物理存储在数据库中，这将最大限度地减少 I/O。该方法不如 XML 灵活，但速度快得多。针对它进行报告的最有效查询将涉及数据透视(即表扫描以生成中间扁平化结果)；加入获取个别字段会慢很多。
最快的方法是拥有一个包含一组用户定义字段(Field1 - Field50)的平面表，并保存一些关于字段内容的元数据。这是最快的插入速度，也是最快且最容易查询的，但表的内容对于任何无法访问元数据的内容都是不透明的。
关于sql-server - 使用键/对表与 XML 字段和 XPath 的 SQL Server 性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2297861/