1

ドキュメント ストレージのソリューションを構築しており、タイトルや説明などの基本データから、関連するイベントの日付、配置、分類ルールに至るまで、地域の規制に準拠するために、ドキュメントごとに多くの追加のメタデータを保存する必要があります。

さまざまなタイプのソリューションを見てきましたが、納得できるものはありません:

  1. 新しいメタデータ スロットが追加されると列が大きくなるテーブル (そのため、ドキュメントに関連付けられたメタデータと同じ数の列があります)
  2. 予備のジェネリック列が多数あるテーブル。1. と非常に似ていますが、テーブルは大きくなりません (権限が少ない)
  3. ドキュメント ID、メタデータ キー、およびメタデータ値のテーブル。
  4. 3. のメタデータ定義とメタデータ キーを含むテーブルは、メタデータ ID に置き換えられます。過去にこのソリューションを使用しました。テーブルの最後には数百万行あります。
  5. キーと値のペアのすべてのメタデータを含む XML またはその他の構造化された情報を格納するドキュメント テーブルまたは関連するテーブル内のテキスト フィールド。

関連するメタデータで検索するための並列フルテキスト インデックス (Lucene.Net? その他?) を提供する (すべてが "検索可能" である必要はありません)、5 番に偏っています。

なにか提案を？似たような経験？

4

3 に答える 3

1

たぶん、 JCR（Javaコンテンツリポジトリ）を見ることができます。JCRは、バージョン管理、全文検索、編集などのコンテンツ管理の一般的な要件をキャプチャするコンテンツリポジトリの標準です。また、コンテンツストレージに一定レベルの要約を提供します。つまり、1つのAPIを使用して、データベースやxmlファイルなどのあらゆる種類のストレージシステムにコンテンツを配置できます。もちろん、いくつかのプロパティを追加することで、ドキュメントにメタデータを追加できます。 JCRAPIを使用したドキュメントノード。ドキュメントとメタデータがどのように保存されるかを心配する必要はありません。JCRが対応します。Jackrabbitは、JCRのリファレンス実装です。試してみてください。

于 2009-05-15T17:16:14.407 に答える
1

CouchDBを使用しないのはなぜですか? このタイプの要件に正確に対応するように設計されています。

それができない場合は、メタデータ記述子として Lua または JSON (#5 オプションによる) を使用することを検討してください。

于 2009-05-08T13:44:16.880 に答える