3

私は SQL の初心者で、次の質問に答える必要があります。何千もの XML ファイル (それぞれに数百のノードがあります) があり、その中のデータの上に Postgresql データベースを構築する必要があります。

私は2つの方法を考えています：

  1. XML ファイルを 1 つ (または複数) の大きなデータベース テーブル (1 つの XML ノード = SQL テーブルの 1 行) に変換し、このテーブルを操作します。
  2. ネイティブ XML タイプのデータベースを作成し (XML タイプのデータをデータベース内に格納)、検索とフィルタリングに XPath を使用します...

どちらのアプローチが優れているでしょうか (より速く、より快適に)? SQL データベース内で XML 型を使用する利点と欠点は何ですか?

4

1 に答える 1

6

オプション (1) はひどいので、そうしないでください。ノードごとに 1 つの行を持つ単一の巨大なテーブルは、 EAVに硫黄臭とボーナスホーンが追加されたように、クエリを実行するのが困難になります。

XML で表されるデータをエンティティ (テーブル) および関係としてモデル化するか、XML ドキュメントを単に DB に格納します。

XML が規則的に構造化されている場合にのみ、XML をエンティティおよび関係として有効にモデル化できます。さまざまな自由形式の XML ファイルが多数ある場合、RDBMS で実際に有効にモデル化することはできません。それらが規則的である場合、これはしばしば最良のオプションです。

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

これを次のようにモデル化できます。

  • と列を持つparentテーブル。とidattrib
  • and列を持つchildテーブルと、への外部キー参照を持つ列。idotherattribparent_idparent(id)

XML を正確にモデル化する方法は、XML によって異なります。何が必須で、何が必須でないのですか? 入力 XML 内のエンティティの正確な順序を再構築する必要がありますか? またはノード内の順序は重要ではありませんか? フリーフォームのネスト可能なエンティティはありますか?

1 種類の決定の例として、特定の子ノード タイプをゼロまたは 1 つ (ただしそれ以上) 持つことができる親ノードがある場合、2 つのテーブルと 1:1 のオプションでそれをモデル化することを選択できます。または、子の属性/コンテンツがnull可能である単一のテーブルで、子要素を親にマージできます。パフォーマンス (結合コストとテーブル幅およびページあたりの行数) と使いやすさの両方の点で、長所と短所があります。

XML 構造が厳密な場合は、テーブルとしてモデル化すると便利なことがよくあります。自由形式の場合、通常は XML として DB に保存し、xpath でクエリを実行する方が便利です。

XML ドキュメントとして保持すると、DB 内でインデックスを作成してクエリを実行するのが難しくなりますが、XML を DB から取得してアプリに渡すのははるかに簡単になります。xpath 式の関数インデックスは非常に役立ちます。XML フラグメントを格納できず、ドキュメント全体のみを格納できるように、フィールドCHECKを強制する制約を追加することも価値があります。xmlIS DOCUMENT

于 2013-03-22T12:36:48.643 に答える