Question

我从几个消息来源获悉，在数据库中存储XML是“糟糕的”，但我从未见过/听到过为什么会这样做的实际解释。这是真的吗？如果是真的，你能解释一下原因吗？此外，您能告诉我在数据库中存储XML的“好”案例是什么？

Answer 1

这里有一些非常愚蠢的答案 - 仅仅因为数据库支持数据类型不意味着您应该使用它。这些东西总是作为特征添加，因为竞争有它们，而不是因为它们是正确的。全局变量？触发器？是否有人愿意为他们辩护，因为你可以使用它们并且它们在那里？

如果您有多个属性，在关系数据库中处理它们的最佳方法是使用一对多关系。从XML开销中解析出有用的数据。然后，您只需存储父记录的ID（主键），每个行存储在第二个表中，每个属性一行。每个父记录可以包含任意数量的属性。这是数据库设计101，没什么聪明的。将它存储为非结构化XML只是为了存储可变数量的属性不是要走的路，它是一个破解花生的大锤。两个表之间的一对多关系更简单，更易于理解，更多查询更快，编码更少，存储更少（这意味着更快的查询）。除了存储供应商之外，每个人都获胜。

XML是数据传输协议;正如GolezTrol正确地说的那样，“这是一种导出（和导入）数据的方式” - 即：它只是用于促进不同系统之间数据结构通信的开销。收到后，标签应该被删除，数据（和仅数据）存储在您选择的数据库引擎中，无论可能是什么。不是XML本身。 XML的开销是它描述的数据的10倍。想告诉你的老板为什么100GB的数据占用昂贵的SAN上1TB的空间？或者通过饱和的网络链接整夜备份？或者在生产中造成性能问题？如果您不解析现在无意义的标签中的数据，您只需将问题和持续的日常支持成本推到未来十年的运营支持中。邋，马虎，马虎。这使像EMC这样的供应商处于业务中。

XML是元数据。没有什么聪明的，只是架构描述符。一旦它被转移和解析它就失去了它的用处，并且只是混乱，阻塞你使用的任何数据库。摆脱它，除非你强迫沉迷于昨天的无意义的蹩脚描述元数据，存储了很多次。醒来。这是典型的“皇帝的新衣”综合症，不再被简单和一次性的东西所束缚。它只是元数据，不应该存储或崇拜，一旦解析它就是垃圾。什么更好？要解析它一次，或者无需每隔时间解析你需要数据吗？答案对我来说很明显。

Answer 2

一点也不差。 Microsoft SQL Server具有XML数据类型。存储XML的一个用例是我们发现的情况。对于特定表中的每一行，我们需要存储与该行相关的可变数量的属性。并且这些属性的数量可以随着时间和每行而变化。我们发现以XML格式存储这些属性及其值更有效。将来，每次调整属性数量时，我们都不需要进行架构更改。

Answer 3

存储XML，JSON，YAML，逗号分隔列表，二进制blob或数据库中的任何其他内容错误 ... 本身。

它可以表示缺乏对数据库用途的理解（存储与其他数据相关的数据），并用单个列表称为data1来形成数据库的愿景， data2等等......每个表行包含一个+5 MB的XML编码关系数据条目。

另一方面，可以为这样的结构制作许多有效的案例 - 快速更改的配置可能用JSON表示并存储在两列表格中，如下所示：

dbo.good_table
ApplicationID (bigint)
Configuration (varchar(max))

上表和这样的表之间的差异：

dbo.bad_table
ApplicationID (bigint)
ApplicationMembers(xml)

good_table是否能够快速访问一段数据（配置），而bad_table正在使用数据库作为昂贵（和慢速）的硬盘。

Answer 4

XML本身就是一种存储格式。它最常用于数据传输，因为它提供了一种结构化数据的通用机制。有一些固定的XML读写规则允许任何人读取XML数据。此外，验证和转换为其他输出格式相对容易（使用xslt）。但是，XML并不是存储数据的最佳方式。读取XML文件非常耗时，并占用相对较多的空间。最好以数据结构的方式将数据存储在数据库中，如果您需要在报告中，网站上将数据从某些查询导出到XML，或将数据传递给其他方。

有XML数据库，但它们也不存储XML中的数据。它们只提供了一种保存和加载分层数据的方法（XML是一种分层结构），而不是标准的表结构。

所以说将XML内容存储在数据库中的blob通常不是正确的方法是正确的，但总会有例外。

XML与其他人在此处所说的不同 - 不是显示数据的方式。这是一种导出（和导入）数据的方法。它是数据传输的合理选择。这是因为您希望它导出的方式非常灵活，它可以很容易地转换为其他格式。比如，如果您有网上商店，并且想要将价格和产品信息导出到其他方，您可以选择XML。这些其他方可以编写简单的规则来将这些数据转换为他们的需求。任何一方都不必知道价格存储在另一方的方式，并且任何一方都不必编写复杂的工具来解析其他人已经编造的难以读取的二进制文件。

Answer 5

不，不是。

实际上，有几个数据库已经有用于存储XML文档的数据类型。

Answer 6

我认为存储数据库可能不是因为速度原因（解析等）。然而，一个很好的例子是它适合半结构化模型，这列出了here的一些优点。

Answer 7

将XML存储在数据库中既好又不好。您只需要考虑自己的要求以及数据的使用方式即可。

如果您的数据是机器生产和使用的，并且只能使用XML在应用程序之间进行传输，那么数据库就很有意义。此时，您可能还需要查看JSON而不是XML，因为它在两个应用程序之间的封装数据传输方面更好（IMO）。

如果您的数据是人工生成的或以文档为中心的，或者可能会定期进行模式更改，或者被读取为文档而被使用，那么保留XML可能更有意义。如果XML对任务至关重要，或者您需要更改记录，那么您也可以考虑使用某种版本控制。

将XML存储在数据库中“不好”吗？

7 个答案: