Postgresql XML类型的优点？

Question

我是SQL的初学者，需要回答以下问题。 我有成千上万的XML文件（每个都有数百个节点），需要在它们内部的数据之上构建一个Postgresql数据库。

我考虑两种方式：

1. 将XML文件转换为一个（或多个）大型数据库表（一个XML节点= SQL表中的一行）并使用此表。
2. 创建一个具有原生XML类型的数据库（在数据库中存储XML类型数据）以及用于搜索和过滤使用XPath ......

哪种方法可以更好（更快，更舒适）？在SQL数据库中使用XML类型有哪些优缺点？

Answer 1

选项（1）很糟糕，不要这样做。每个节点有一行的单个巨型表将糟糕进行查询，like EAV添加了含硫臭味和额外的角。

模型将XML表示的数据作为实体（表）和关系，或者只是将XML文档存储在数据库中。

如果XML是定期构建的，那么您只能将XML建模为实体和关系。如果您有一堆不同的自由格式XML文件，那么您无法在RDBMS中对其进行有效的建模。如果他们是常规，这通常是最好的选择，例如：

<root>
   <parentnode attrib="value">
      <child otherattrib="value2">content</child>
   </parentnode>
   <...>
</root>

您可以将其建模为：

• 包含parent和id列的attrib表格;和
• 一个child表，其中包含id和otherattrib列以及parent_id列，其中包含对parent(id)的外键引用。

究竟如何建模XML取决于XML。什么是强制性的，什么不是？您是否需要重新构建输入XML中实体的确切顺序，或者节点内的顺序无关紧要？是否有自由形式的可嵌套实体？

作为一种决定的示例，如果您的父节点可以具有零个或一个（但不多于）给定子节点类型，您可以选择使用两个表和一个1来对其进行建模：1个可选关系，或者您可以将子元素合并到子属性/内容可为空的单个表中的父元素中。在性能（连接成本与表宽和每页行数）和易用性方面都有优点和缺点。

如果XML结构严格，那么建模为表通常很方便;如果它是自由形式的，那么将它作为XML存储在数据库中并使用xpath进行查询通常更有用。

如果将其保留为XML文档，则在数据库中进行索引和查询会更加困难，但更容易将XML从数据库和应用程序中取出。 xpath表达式上的功能索引可以提供很多帮助。还需要添加CHECK约束来强制执行xml字段IS DOCUMENT，这样您就无法存储XML片段，只能存储整个文档。