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

Question

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

从正面看：

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

从反面看：

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

这些理据是否正确？还有人能想到更多吗？

Answer 1

没有一个真正明确的职业骗局清单-它取决于你想要做什么。但这里还有几个值得你思考的问题：

1. 并非所有的SQL数据库都支持xpath (除了blob like '%xxx%')。也许您被困在一个旧版本的数据库上，它没有XML支持功能(即Mysql 4)。较轻的SQL数据库(如Sqlite和hsql )也属于这一阵营。
2. 即使可以在数据库中搜索XML，它也不是最优的。XML的SQL搜索不能利用SQL服务器内置的搜索优化(即索引)。
3. 根据数据库的不同，您在数据库中使用的XML文档也不能利用SQL server的验证和类型特性。例如，Oracle可以进行XML模式验证，但我认为Mysql不能。
4. 对于您可以执行的查询，性能不能与标准列查询相比。
5. 数据库大小。如果将XML存储在数据库中，它将更大。你可以压缩它，但是查询它是困难的/不可能的。
6. 归一化问题可能会成为相关的问题--也许您不会期望在某个时候使用SQL来查询XML，但是在以后的某个时候，它决定实际上需要一些字段。您可能需要将该字段从XML中提取出来，并填充一个实际的列，以获得所需的performance...in，此时数据库中有多余的信息。

优点和缺点实际上取决于您将存储什么，以及它的目的。

1. 如果它本质上是二进制/配置信息，您只需要将其放在某个位置，并且无论出于什么原因，您都更愿意停留在SQL database...well中，那么有关查询的注意事项就不相关了。在这种情况下，重要的问题将涉及空间和如何将其最小化(即压缩)。
2. 如果有任何可能需要定期搜索XML，那么您就会面临查询速度慢和前面提到的冗余问题的风险。在这种情况下，您应该在前面非常仔细地考虑您的长期设计:您真的需要将这些数据存储为XML吗？从这些数据构建XML会更好吗？

Answer 2

这两种情况都有优缺点，这取决于您的使用场景。

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

我们在一个项目中遇到了类似的情况。在讨论了它之后，我们采用了一种中间的方法:所有主要信息(需要快速查询的信息)都存储在相关的表中。我们还存储了XML；但是，我们没有存储XML本身，而是将XML保存到磁盘中，并在表中使用该文件路径。

Answer 3

讨论你的评论：

1. 不存储单个元素也意味着不对其强制执行约束。
2. 同样，表之间的约束没有存储。
3. 只有当目标系统确认为同一架构时，才可移植。
4. 是的，但是演出会有所不同。