将XML存储在关系数据库中的基本原理

Question

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

在侧：

1. 没功夫分解到表的各个元素和atrribute到列
2. 没有精力来维护表之间的关系，因为它们包含
3. 便携式跨系统中的XML自我共享XML
4. 如果有需要，从字面上看，所有的DBMS都支持XML操作来将XML作为关系实体进行查询。

不利的一面：

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

这些理由是否有效？任何人都可以想到更多？

Answer 1

有没有一个真正的权威专业清单 - 它取决于你想要做什么。但是，您可以考虑以下几项：

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

优劣取决于你要存储什么，以及它的用途。

1. 如果它基本上是二进制/配置信息，你只需要粘在某个地方，并且出于任何原因喜欢坚持在你的SQL数据库中......好吧，关于查询的考虑是不相关的。在这种情况下，重要的问题将涉及空间以及如何最小化它（即压缩）。
2. 如果有可能需要定期搜索XML，那么您将面临缓慢查询和上述冗余问题的风险。在这种情况下，您应该非常仔细地考虑您的设计：您是否真的需要将这些数据存储为XML？从这些数据构造XML会更好吗？

Answer 2

在这两种情况下都有正反两面，它取决于您的使用场景。

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

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

Answer 3

讨论你的意见：

1. 不存储各个元素也意味着不强制对他们的约束
2. 同样也不会被存储表之间的约束
3. 只有在目标系统确认相同的便携架构。
4. 是的，但性能会有所不同。