1

我需要解释为什么我们需要将 XML 文档存储在数据库中。

在好的方面：

  1. 无需将单个元素分解为表格并归属于列
  2. 无需维护表之间的关系，因为它们自包含在 XML 中
  3. 可跨共享 XML 的系统移植
  4. 如果有需要，实际上所有 DBMS 都支持 XML 操作以将 XML 作为关系实体进行查询。

不利的一面：

  1. 网络有效负载比 RDBMS 计数器部分大得多。
  2. 要求客户端应用程序将它们分解为可用组件。

这些理由是否有效？谁能想到更多？

4

3 回答 3

4

没有真正的明确的赞成名单 - 它取决于你想要做什么。但这里还有几个供您考虑：

  1. 并非所有 SQL 数据库都支持 XML xpath（超出blob like '%xxx%'）。也许您被困在一个不支持 XML 功能的旧版本的数据库上（例如，Mysql 4）。Sqlite 和 hsql 等更轻量级的 SQL 数据库也属于这个阵营。
  2. 即使可以在数据库中搜索 XML，它也不是最优的。XML 的 SQL 搜索不能利用 SQL 服务器内置的搜索优化（即索引）。
  3. 根据您使用的数据库，数据库中的 XML 文档也无法利用 SQL 服务器的验证和类型功能。例如，Oracle 可以进行 XML 模式验证，而我看不到 Mysql 可以。
  4. 您可以执行的查询的性能无法与标准列查询进行比较。
  5. 数据库大小。如果您将 XML 存储在数据库中，它会变得更大。你可以压缩它，但是查询它会很困难/不可能。
  6. 规范化问题可能会成为相关问题 - 也许您不希望在某些时候使用 SQL 来查询 XML，但后来它决定实际需要某些字段。您可能需要将该字段从 XML 中提取出来并填充一个实际的列，以便获得所需的性能……在这种情况下，您现在的数据库中有冗余信息。

利弊实际上取决于您将要存储的内容及其用途。

  1. 如果它本质上是二进制/配置信息，您只需要粘贴在某个地方，并且出于某种原因更喜欢粘贴在您的 SQL 数据库中……那么，关于查询的考虑是不相关的。在这种情况下，重要的问题将涉及空间以及如何将其最小化（即压缩）。
  2. 如果有任何可能需要定期搜索 XML，那么您将面临查询缓慢和我上面提到的冗余问题的风险。在这种情况下，您应该预先仔细考虑您的长期设计：您真的需要将这些数据存储为 XML 吗？从该数据构造 XML 会更好吗？
于 2012-04-14T13:25:23.807 回答
3

讨论您的评论：

  1. 不存储单个元素也意味着不对它们实施约束
  2. 同样，不存储表之间的约束
  3. 仅当目标系统确认相同的模式时才可移植。
  4. 是的，但性能会有所不同。
于 2012-04-14T12:43:34.507 回答
3

这两种情况都有利有弊，这取决于您的使用场景。

存储为 XML 本身的主要缺点是我们无法快速搜索特定数据。要执行搜索，我们必须检索并解析所有 XML 文件。

我们在一个项目中遇到了类似的情况。经过讨论，我们采取了一种中间立场：所有主要信息（需要快速查询的信息）都存储在相关表中。我们还存储了 XML；但我们没有像这样存储 XML，而是将 XML 保存到磁盘并在表中使用该文件路径。

于 2012-04-14T11:53:25.617 回答