xml - 在数据库中存储 XML 是 "bad"吗？

Question

我从多个来源听说将 XML 存储在数据库中是“不好的”，但我从未看到/听到过关于为什么会这样的实际解释。是真的吗？如果是真的，你能解释一下为什么吗？此外，您能告诉我在数据库中存储 XML 的“好”案例是什么吗？

Answer 1

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

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

XML 是一种数据传输协议(protocol)；正如 GolezTrol 所说，“这是一种导出(和导入)数据的方式”——即:它只是一种开销，用于促进不同系统之间数据结构的通信。收到后，标签应该被剥离，数据(仅数据)存储在您选择的数据库引擎中，无论是什么。不是 XML 本身。 XML 的开销大约是它所描述数据的 10 倍。想告诉你的老板为什么 100GB 的数据占用了你 super 昂贵的 SAN 上的 1TB 空间？或者通宵备份一个饱和的网络链接？或者导致生产中的性能问题？如果您不从现在毫无意义的标签中解析出数据，您只会将问题和持续的日常支持成本推到 future 十年的运营支持上。马虎，马虎，马虎。这使像 EMC 这样的供应商得以继续经营。

XML 是元数据。没什么聪明的，只是一个模式描述符。一旦它被传输和解析，它就失去了它的用处，只是杂乱无章地阻塞了你使用的任何数据库。摆脱它，除非你强制性地沉迷于储存昨天毫无意义的蹩脚描述元数据，存储了很多次。醒来。这是典型的“皇帝的新衣”综合症，不再被简单和一次性的东西所欺骗。它只是元数据，不应该被存储或崇拜，一旦被解析就是垃圾。什么更好？是一次解析它，还是每次您需要从中获取数据时无用地解析它？答案对我来说非常明显。