sql - 您何时选择将 XML 存储在关系数据库中？

Question

可能重复：
为什么我会选择在关系数据库中存储和操作 XML？

尽管表面上这个问题似乎是对之前已经提出的问题的重新讨论，但我会预先声明它不是。我的问题不是如何从关系数据库中存储或检索 XML。手头的问题比这更根本：

您通常在数据库中以 XML 格式存储什么类型的数据？您这样做的设计决策是什么？您是否愿意通过将模型的某些部分放入 XML 简介中来放弃数据库的“关系”方面？诸如首选项或配置文件之类的东西可以作为 XML 存储在关系数据库中，但您应该这样做吗？

Answer 1

绝不。

将具有某种可识别结构的数据存储为 XML，而不是关系数据，意味着放弃关系代数对该数据进行操作的能力。

如果这是您的意图，那很好，但请坦诚相待，根本不用费心使用关系 DBMS，只需将您的 XML 转储到一些本地/伪本地文件中。

（请注意，存储在文件系统中的任何内容也都构成数据库，因此该解决方案并不意味着您“不使用数据库”。您只是没有使用关系管理的数据库，而这正是您要启动的意图。 )

Answer 2

恕我直言，将 XML 放入数据库的唯一原因是您需要与项目交互、编辑或更改数据。如果您只是阅读和使用 XML 数据，只需将其放入文件中即可。但是，如果应用程序正在修改或添加该数据，则最好使用 DB，并且您根本不需要 XML，因为该表将描述数据的结构。

Answer 3

我在关系数据库中存储 XML 的经验通常是出于历史目的或作为持久性策略的一部分存储序列化对象，并假设我稍后将检索此 XML 并将其重新水化为对象。

Answer 4

您的代码可能希望通过以下方式处理 XML 数据：

1. 只将它保存在数据库中，在业务层中进行所有处理，例如发送到/来自 Web 服务的 SOAP 消息的队列或审计跟踪。为此，我将使用一个简单的文本列。
2. 将它保存在数据库中并在数据库层中运行偶尔的查询，例如用户可以搜索的 XHTML 文档。为此，我将使用xmlSQL Server 2005 或更高版本中的数据类型，或其他 DBMS 中的等效数据类型。
3. 数据库层中的全面复杂关系查询，例如，仅序列化为 XML 并且现在必须以正确形式存储的关系数据块。这显然会存储在与反序列化数据结构匹配的表集中。

Answer 5

我使用这些条件在数据库中存储 XML 数据。

1. 我没有时间开发关系表（真的，我有时会以这种方式开始，只是为了让原型启动并运行）。

2. 数据非常庞大且结构复杂，无需花费大量精力即可拆分成表格

一般来说，我喜欢将关系数据存储在我的数据库中，但想象一下我有一个对象，它代表了呈现网页所需的所有数据（我的意思是一切，字体，图像），它会非常复杂，存储它在表格结构中，实际上只会引起我的维护问题 - 结构是流动的。它也会导致我的查询问题——想象一下我需要做的连接数量，以及它需要的时间。

Answer 6

当数据本身不需要有关系时，我倾向于存储 xml 简介（或其他不透明数据，如 json 序列化）。