在关系数据库中存储xml有什么优势？

我AdventureWorks数据库今天闲逛，我注意到，一些表（HumanResources.JobCandidate并 Sales.Individual举例）具有被存储XML数据的列。

我要知道的是，基本上将数据库表行的数据存储在另一个表的列中的优点是什么？这是否使查询这些信息变得困难？还是假设不需要查询数据而只需要存储数据？

因为并非所有数据都需要进行关系存储并编写代码来处理数据，所以您已经将XML作为关系存储进行了传递，这非常耗时（而且非常繁琐）。当大量XML数据来自抛出大量通用响应的系统时，尤其如此。

我经常看到从其他系统收到消息的情况，而我们并不关心其中包含的98％。因此，我们将其解析为我们关心的2％，将其存储起来，然后存储整个消息，以防以后我们需要其余98％中的任何一个。

而且，SQL Server为您提供了一些可以在T-SQL中使用XML的工具和语法，因此，就好像您存储（例如）目录内容的方式一样，对于临时查询来说，这似乎完全超出了实际范围CSV。

而且这排除了您实际想要存储的是XML（例如出于支持和调试目的）的可能性...

如果数据格式易变且可能会发生更改，则您可能希望将其作为XML放在一起并以这种形式放入数据库中，从而避免将来更改数据库架构。

在相同的切线上，如果数据是由某个外部系统提供并再次被其使用，并且它们无法为您提供永久格式，那么您将要这样做。

这是否使查询这些信息变得困难？

SQL Server可以查询XML字段和变量。不一定困难，但是更多的工作，是的。但是可行。

以我的经验，XML数据通常是存储的，很少查询，但是经常在必要时提取，通常是在其他系统需要某些数据的XML表示形式时，很难或不可能从关系数据中即时生成。XML数据可能已通过其他一些过程进行了预填充。

如果您可以想象将数据存储在二进制流中的Blob中，那么我可以想象您可以想象将数据以xml格式存储在Blob中。

当然，很多东西最好留在想象者的想象中。

举例来说，电子病历：

由于您很可能将ASCII HL7 V2.x存储在数据库的字段中。您可能倾向于将HL7 V3.0存储在数据库的字段中。

因此优点是方便。

我目前正在做一个能做到这一点的项目。我们有需要多次处理的数据，并且需要进行关联存储。但是，处理是在Java中完成的，在那里使用XML更容易。因此，我们对关系数据进行了一次遍历，并将其作为XML存储在表中。然后，我们可以使用一个非连接查询在Java中处理该数据，而不是每次都检索数据，然后一遍又一遍地处理相同的数据，直到我们的内心深处。它更简单，更有效。

当您要在数据库中保留UI状态时，就是存储XML的一个很好的例子。所有应用程序视图的状态都已序列化并存储在数据库中，无需查询XML。UI状态是指视图排序顺序，窗口大小等。

通常，您会同时获得XML和关系数据。（一个很好的示例是文档存储，其中每个文档都可以具有元数据字段，例如标题，创建日期，所有者等。）

此时，您必须从以下三个选项中进行选择：

1. 将所有内容存储在关系数据库中。
2. 将所有内容存储在本地XML DB中。
3. 将数据存储在两个单独的DB中，本机XML中的XML和关系型元数据。

选项3可能是最干净的，但也是实现起来最昂贵和最困难的，此外，您不一定要在不太大的系统中使用分布式事务。选项2不太好，因为本机XML数据库通常在处理关系数据方面非常差（您更可能在搜索中使用它），并且该技术总体上不如关系数据库成熟。

因此，这给您留下的选项1当然不是最好的解决方案，但可能是最坏的解决方案。

以我的经验，在数据库中使用XML最终是因为这就是数据源存储XML的方式，或者您将其添加到现有数据库中以扩展功能，而无需大量数据库编程即可支持。

如果您要经常搜索新数据，则可以将XML拆分为其组成部分。如果没有，这可能是保存不经常更改的数据的有用方法。

希望这会有所帮助，杰夫

如今，面向文档的数据存储（又名NoSql）非常流行：

http://zh.wikipedia.org/wiki/面向文档的数据库

没有理由不能在关系数据库中采用面向文档的方案。与Mongo之类的东西相比，您可能不会获得所有相同的好处，但是您也不会遇到任何缺点。

长期以来，如果要使用面向文档的存储，唯一的选择就是将结构化数据（如XML）推入一个大列中。关系数据库已经添加了索引和匹配之类的功能来支持该功能。

与Mongo相比，它们在数据库中唯一的内容就是文档。但这是另一个话题。

编辑：面向文档的核心思想是：提取数据，对其进行操作，然后将其整体推回去。有时，例如当您将文档传输到客户端时，您只想将整个内容作为Blob发送并让他们处理。优点（和缺点）是灵活性。文档的验证和正确性是在数据库外部完成的。

编辑编辑：另一个对比。想象一下将JPG图像或Word文档保存在数据库列中。

在元组列表（数据库表）中存储树（XML）有什么优势？

没有理由不能使用XPath或SPARQL从您的DBMS查询XML。

如我所见，它们只是两个不同的数据结构。而且没有理由不应该将它们相互嵌入。

您可以查找在PostgreSQL中添加JSON数据类型的原因。我认为许多相同的论点都适用。除了使用XML / XSD之外，还可以进行更多验证。

好吧，XML（或JSON）非常适合存储具有层次结构的元数据。有哪些选择？具有refid / key / value / depth的元数据表可能是？这有点麻烦（但如果需要的话，可能更适合查询）。当您要存储一些层次结构信息而不必依赖外部表或每种“类型”的信息必须添加一列时，存储有关文档的一些xml数据（文档表中的一行）非常方便。

我会说这是一种不好的做法，因为您会用低效的标签堵塞本来有效的存储，如果您努力解析信息，则不需要在那里。与XML所描述的数据相比，XML的存储开销非常大，因为每一行的每一列都需要一个标签。相比之下，解析出并以关系格式存储的数据的列名存储为ONCE。对于开发人员的十几行。框，没什么大不了的，但是我已经看到开发人员假设它可以扩展到数百万行。对于几十GB的数据，这可能代表100 GB的开销，这带来了运营挑战。您基本上是在放弃自己的责任，而要推卸那些必须支持您撰写的废话的人。

那么，为什么不将其与运营数据存储在自己的数据库中呢？还是按预期-平面文件？它可能再也不会被查看了，那么为什么不将其从影响操作系统性能的方面移除呢？请记住，XML仅用于提供对数据模式的描述，否则由于系统之间的存储协议差异，该数据模式将不明显。这就是要点，没有什么聪明的。对于给定数量的数据，要存储10倍的开销，就说明您是个草率的开发人员，他不会考虑所有事情，也不会担心将要消耗的数据处理为明智，高效，快速的查询格式。停止将精力投入到运营支持上，并思考在您完成后如何更好地处理数据 我已经接到了我的电话。接收到数据后将其存储为XML是没有用的，因为它已达到其目的。