12

最新のRDBMSは、XML列タイプとストアドプロシージャでXMLを処理するための機能をサポートしています。歴史的に、私は常に階層データ（OOオブジェクトまたはXML）をリレーショナルテーブルにマップしていました。XMLに対するデータベースのサポートが広まっていることを考えると、自分のやり方を変える必要がありますか？

4

11 に答える 11

5

必要性がわからない場合は、変更しないでください。

既知の構造を持たないデータや、その構造が非常に不安定なデータを永続化する必要がある場合があります。そのような場合、テーブルを作成する代わりに、XML を既存のテーブルに保存するだけです。

于 2008-10-08T20:33:23.763 に答える
5

私は良い実例を持っています。私の顧客の 1 人が、サプライヤから重要なデータを含む XML ファイルを頻繁に受け取ります。深く入り込んでいます。以前の XML ファイルと比較して、何が変更されたかを確認する必要があります。データベースで XML がサポートされていないため、XML ノードを繰り返し処理し、リレーショナル データベースのテーブルで一致を探すツールを作成する必要がありました。XML-XML 比較ツールを使用することもできますが、一部のチェックは、XML ファイルに由来しない他のデータに関連しているため、それらすべてを結合する必要があります。わかりました、これはすべて大したことではありませんが、それでも - XML データベースを使用すると、その機能をすぐに利用できます。

于 2008-10-08T20:59:34.850 に答える
4

私が再びそれを使用する唯一の理由は、拡張性と柔軟性のためです。

xml (xpath) とメンテナンス (名前空間) のオーバーヘッドは、回避できるのであれば、それほど面倒なことではありません。以前は大量のデータを xml に保存し、スカラー関数を使用してそれを取得していましたが、xml 構造または名前空間の変更があまりにも遅く、大きな頭痛の種となっています。

しかし、柔軟性は素晴らしいです。必要なときにいつでも新しいプロパティを追加できます。適切な列を必要としないプロジェクト/クライアント/ジョブ固有のデータをそこに含めることができます。XML は静的構造である必要はありません。異なる XML (プロジェクト/クライアント/ジョブに関連付ける必要がある) を処理するインスタンスを生成できるファクトリが必要なだけです。

新しいテーブルを既存のシステムに追加する場合、特に既存のデータが多く、簡単に変更できないシステムに追加する場合は、XML 列を追加します。将来、そのテーブルに別の列を追加する必要が生じた場合でも、イライラして何度もやり直す必要がなく、単純に XML 列を利用できます。

要約すると、XML に不可欠なプロパティを配置することから始めません。ただし、テーブルを拡張する必要があることがわかっている場合は、XML を追加する必要があります。XML を追加すると拡張のオプションが得られるからです。

于 2009-09-01T10:49:13.743 に答える
3

XML列タイプを使用して、サードパーティのサービスから受信するすべてのビジネスクリティカルなメッセージのコピーを隠します。いくつかの理由で非常に便利です。

1）データが破損した場合は、バックトレースして、どのデータがいつ、どの形式で受信されたかを確認できます。
2）システムの将来の開発作業は、ログテーブルの実際のデータに基づくことができます
-3pサービスの呼び出しからのものであるかのようにデータを逆シリアル化して使用します3）インフラストラクチャ担当者がDBにディスクスペースを割り当てるのに忙しいことを確認しますサーバ。;）

于 2009-09-01T10:26:49.950 に答える
3

これは、私が取り組んでいるシステムの実際の例です。私たちはコアシステムを持っており、Java で顧客固有のコードを作成します。どの顧客が取引しているかによって、異なるクラスが呼び出される場合があります。場合によっては、このカスタム コードに何かを格納する必要があり、関連するテーブルの XML 列に配置します。これにより、太陽の下ですべてをモデル化する必要がなくなります。通常、新しい顧客を追加することは、Java コードを作成してインストールすることを意味します。

欠点は、レポート、クエリ、および更新が XML 列でより困難になることです。チェック制約などの通常の優れたデータベース機能はありません。

于 2008-10-20T13:31:33.583 に答える
2

たとえば、保存したい非常に豊富な構造または複雑な構造を持つ XML ドキュメントを他のシステムから取得するとします。ただし、そのデータを取得するために必要なのは、適切に定義されたクエリがいくつかあるだけです。その場合は、必要なデータを解析していくつかのインデックスを生成し、XML 構造全体を 1 つのフィールドに格納します。

これを行うには、DB エンジンで XML 固有のサポートをあまり必要としませんが、それでもクエリを表現力豊かに保つのに役立ちます。

それに加えて、XML を適切にサポートする DMBS の中には、XML ドキュメントを簡単に保存できるものもあると思います。おそらく、インデックスの作成方法を指定する必要はありません。XQuery を使用するだけで、それが何らかの形でニーズに最適化されることを願っています。

于 2008-10-08T20:55:12.877 に答える
1

XML データを SQL サーバーで直接処理できます。たとえば、XPath 式を適用して、フィルタリングされた結果セットをクライアントに送信するだけです。SQL サーバー機能は、後で XML 処理機能に基づいて構築できます。

上記の機能は、MS SQL Server 2000または 2005 から存在します。

于 2008-10-08T20:39:56.513 に答える
1

属性を持つエンティティがあるとします。個別の属性テーブルを作成する代わりに、これらの属性をすべて XML に格納できます。XML の方が柔軟です。

于 2008-10-08T20:32:02.487 に答える
1

これまで XML を保存する必要はありませんでしたが、ストアド プロシージャから XML を返す機能を頻繁に使用しています。それはいくつかのことを非常に便利にします - 主にレポートです。SP を実行してレポートを生成し、結果を XML で送り返し、XSLT を使用して結果をサイトに簡単に表示できます。

于 2008-10-20T13:41:41.113 に答える
0

ユーザーが生成した XML をそこに格納できます。

stackoverflow のような Web サイトがマークダウンではなく何らかの XML マークアップを使用している場合、質問/回答を XML としてデータベースに保存できます。独自のタグを探して、このユーザー生成 XML を解析しようとしていることに気付くかもしれません。

于 2008-10-08T20:26:54.697 に答える
0

柔軟性が理由の 1 つです。

データの構造が変化する可能性がある場合でも、共通の RDBMS テーブルをクエリなどと共に保持し、多少変化する構造のデータを使用することができます。

ある時点でフィールドを追加する必要がある場合、RDMS テーブル構造を変更せずに追加できるため、他のユーザーのクエリを壊すことはありません。

于 2008-10-08T20:36:17.503 に答える