製品データを保持するために使用する SQL テーブルがあります。一部の製品には、他の付属データがあります (書籍にはページ数、表紙の種類、映画には時間の長さなどがあります)。
SQL で別のテーブルを使用してそれらを保持し、(名前、値) のペアを保持することができます。
XML で圧縮されたデータをテーブルの 1 つのフィールドに保持することもできます。これは正規化されたアプローチではありませんが、私にとってはより自然に思えます。
4 に答える
3
ショッピング バスケット アプリケーションでも同様のことを行いました。スキーマをあまり作成せずに製品にメタ データを添付する必要がありました。スキーマを作成すると、将来的にメタデータの形式が制限されることになります。メタデータを XML として保持しました。
私がそうしない唯一の理由は、データに対してクエリを実行することになる場合です。パブリッシャーのメタデータや何か (私に起こったこと) によるレポートを欲しがる愚かな人がいないことを確認してください。
于 2009-09-17T09:02:47.477 に答える
1
データベーステーブルを適切に定義しない方法としてXMLを使用するつもりだった場合、それは実際にはアーキテクチャ上のコップアウトになります。あなたのシナリオについてはよくわかりませんが、危険なほどそれに近いようです。しかし、キーと値のペアはおそらくもっと悪いです。
データベースにスペシャリストXMLデータ型がある場合は、スペシャリストXMLデータ型を使用するのが最善です。RageZのリストに加えて、Oracleは10年間（9i以降）XMLTypeを持っていました。XMLTypeを使用する利点は2つあります。この列のドキュメントがXMLであることをカジュアルオブザーバーに通知します。また、必要に応じて、XMLスキーマによる検証などの組み込み機能にアクセスできます。その後、XMLの内容を参照し始める必要がある場合は、他の機能が便利であることがわかります。たとえば、OracleのXDBは、XPathクエリのパフォーマンスを劇的に向上させることができるXMLインデックスタイプをサポートしています。
于 2009-09-17T09:41:15.543 に答える
0
場合によります！
製品の「形状」が大きく異なることが予想される場合は、XML を使用することをお勧めします。[SQL Server を使用している場合は、XML フィールドにインデックスを付けることができます。]
于 2009-09-17T09:02:47.317 に答える
0
私はそれが建築上の誤解だとは思いません。複雑になるため、クエリでこれらのデータを使用したくないことを確認してください。
さらに、最近の RDBM には XML (MSSQL、Postgres、Mysql) を処理する機能があるため、それらのデータを引き続き使用できます。
于 2009-09-17T09:03:12.840 に答える