5

アプリケーションの XML BLOB を格納するために SQL Server を使用する予定です。私は設計上の決定に苦労しており、このトピックの経験者からのガイドラインやアドバイスを探しています.

XML として格納する必要があるデータには、約 100 個の単純なデータ ポイントがあります。それらは、それぞれおそらく 20 個のデータ ポイントのグループに簡単に分類できます。アプリケーションの将来のバージョンでは、新しいデータ ポイントを追加してデータの範囲を拡大する予定です。その一部は階層化されます (リスト、辞書など)。

XML データに対してクエリを実行する必要があるとは考えていません。せいぜいそれらは非常に単純なクエリであり、必要に応じて任意のデータ ポイントをリレーショナル列に昇格させることができます。

このすべてのデータを保持するために 1 つの巨大な XML BLOB を作成するだけでよいのか、それとも複数の XML 列に分割する必要があるのか​​がわかりません。SQL Server 2008 R2 で XML データ型を処理するためのベスト プラクティスやガイドラインはありますか? それも問題ですか？

編集: XML をデータ型として使用することに既に設定されています。1 つの大きな BLOB を使用するか、複数の XML 列に分割するかを決定しようとしています。

4

3 に答える 3

6

Yes it matters! When you store a large XML blob as XML datatype inside SQL Server, then it's not stored as a textual blob - it's "parsed" and "tokenized" and stored in a significantly more efficient manner than if you're using just varchar(max) to store the textual representation.

If it really looks like XML, smells like XML and quacks like XML - then definitely USE the XML datatype!

更新: XML を全体として保存および取得するだけの場合 - チャンクに分割してもメリットはありません。XMLSQL Serverのデータ型は( と同様に) 2 GBvarchar(max)までのデータを保持でき、複数の小さな XML フラグメントを格納 (および取得) してもパフォーマンスは向上しません。

于 2013-08-07T05:18:08.833 に答える
0

はい。

XML の格納には nvarchar(MAX) を使用することをお勧めします。（近い将来）変更する予定がある場合は、（xmlではなく）jsonを保持するようにストレージを変更するため、Jsonを保持することは非常に柔軟です。ただし、XML データ型を使用することを選択した場合、XML のみを使用するのは厳密ではありません。ただし、Mark が述べたように、それが本当に XML のように見え、XML の匂いがし、XML のように鳴くなら、間違いなく XML データ型を使用してください。また、ビジネス ユース ケースで XML 全体を一度に挿入および取得するように指示されている場合、パフォーマンスのチャンクに分割するメリットはあまりないと思います。

于 2014-01-10T08:54:55.657 に答える
0

フィールドがアプリケーションのペイロードを格納するために使用され、アプリケーションが構造のバージョン管理や将来の変更を適切に処理できる場合は、xml フィールドを使用します。xml として保存することの唯一の欠点は、フラット化されたデータとは対照的に、クエリに時間がかかることです。アプリが xml として処理されるすべてのデータを処理する場合、これはジャンプするための小さなハードルになります。

于 2013-08-07T03:01:24.297 に答える