我计划使用 SQL Server 为我的应用程序存储 XML BLOB。我正在为设计决策而苦苦挣扎，并正在寻找有此主题经验的人提供的任何指导或建议。
需要存储为 XML 的数据有大约 100 个简单的数据点。它们可以很容易地分为每组可能有 20 个数据点。在未来版本的应用程序中，我们计划通过添加新数据点来扩大数据范围，其中一些将是分层的（列表、字典等）。
我们预计不需要对 XML 数据执行查询。最多它们将是非常简单的查询，如果需要，我们可以将任何数据点提升到关系列。
我不确定是否应该只创建一个巨大的 XML BLOB 来保存所有这些数据，或者是否应该将其分解为多个 XML 列。在 SQL Server 2008 R2 中处理 XML 数据类型是否有任何最佳实践或指南可以帮助我做出最佳决策？这还重要吗？
编辑：我已经开始使用 XML 作为数据类型，我正在尝试决定是否应该使用一个大 BLOB 或将其分解为多个 XML 列。
是的，这很重要！当您将大型 XML blob 作为数据类型存储在 SQL Server 中时，它不会存储为文本 blob - 它是“解析”和“标记化”并以比仅用于存储文本表示的XML方式更有效的方式存储varchar(max).
如果它真的看起来像 XML，闻起来像 XML，又像 XML，那么肯定使用数据XML类型！
更新：如果您只打算将 XML 作为一个整体进行存储和检索 - 我认为将其分解成块没有任何好处。SQL Server 中的XML数据类型最多可以容纳2 GB的数据（就像varchar(max)），并且您不会看到存储（和检索）多个较小的 XML 片段带来的任何性能提升。
如果该字段将用于存储应用程序有效负载并且应用程序可以正确处理版本控制或未来对结构的修改，那么我将使用 xml 字段。存储为 xml 的唯一缺点是查询可能比扁平化数据更耗时。如果您的应用程序处理所有以 xml 形式传递的数据，那么这将成为一个较小的障碍。
是的。
推荐使用 nvarchar(MAX) 来存储 XML。因为，如果（不久的将来）您计划更改它，修改您的存储以保留 json（而不是 xml），那么为您保留 Json 将非常灵活。但是，如果您选择使用 XML 数据类型，那么只使用 XML 是很严格的。然而，正如 Mark 所提到的，如果它真的看起来像 XML，闻起来像 XML，又像 XML，那么肯定使用 XML 数据类型！而且，如果您的业务用例说要立即插入和检索整个 XML，那么我认为将其分解成块对性能没有太大好处。