何时选择将XML存储在关系数据库中?[复制品]

从未。

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

如果这正是您的意图,很好,但是请坦率地说,不要费心使用关系数据库管理系统,只需将XML转储到某个本地/伪本地文件中。

(请注意,文件系统中存储的任何内容也构成了数据库,所以这不像解决方案所说的“不使用数据库”。你只是没有使用一个关系式管理的,这是你的初衷。)

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

imho,将xml放入数据库的唯一原因是您是否需要与项目交互、编辑或更改数据。如果只是读取和使用xml数据,只需将其放入一个文件中。但是,如果应用程序正在修改或添加该数据,那么最好使用一个db,而您根本不需要xml,因为表将描述数据的结构。

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

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

当数据本身不需要有关系时,我倾向于存储XML模糊(或其他不透明的数据,如JSON序列化)。

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

1. 我没有时间来开发关系表(实际上,我有时是从这种方式开始的,只是为了让原型启动并运行)。

2. 数据大到多,结构复杂,不费很大力气就可以分解成表

一般来说,我喜欢将关系数据存储在数据库中,但假设我有一个对象,它表示呈现网页所需的所有数据(我指的是所有内容、字体、图像等),它将非常复杂,将它存储在表结构中只会让我更容易维护。enace问题-结构是流动的。这也会导致我的查询问题-想象一下我需要做的数字连接,以及所需的时间。