エンティティメタデータストレージアーキテクチャ

Question

ドキュメントストレージのソリューションを構築しています。各ドキュメントには、タイトルや説明などの基本データから関連イベントや廃棄および分類ルールの日付に至るまで、現地の規制に準拠するために多くの追加メタデータを格納する必要があります。

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

1. 新しいメタデータスロットが追加されたときに列で成長するテーブル（したがって、ドキュメントに関連付けられているメタデータと同じ数の列を持っています）
2. 予備の汎用列が多数あるテーブル。 1と非常によく似ていますが、テーブルは成長しません（アクセス許可が少ない）
3. ドキュメントID、メタデータキー、メタデータ値の表。
4. 3のメタデータ定義とメタデータキーを持つテーブルは、メタデータIDに置き換えられます。過去にこのソリューションを使用しました。テーブルの最後には数百万行あります。
5. XMLまたはその他の構造化された情報とキーと値のペアのすべてのメタデータを格納するドキュメントテーブルまたは関連テーブルのテキストフィールド。

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

提案はありますか？同様の経験？

Answer 1

表1：ドキュメント情報（PKはドキュメントID）

表2：メタデータ定義（PKはメタデータ定義ID）

表3：ドキュメントID、メタデータ定義ID、メタデータ値

これの最大の欠点は、単一の型（varchar、おそらく）を持つ必要があるか、n列（nは保存するデータ型の数）を持つ必要があることです。 ）、メタデータ定義テーブルの列を使用して、値を取得するテーブル3の列を特定します。

リストされている5つのソリューションに関する私の意見：

1. テーブルの成長は苦痛であり、将来的に問題を引き起こす可能性があります（特に、null不可のメタデータ値が必要な場合/必要な場合）。
2. 私は「一般的な列を予備」に情熱を注いでいます（人気がありますが）。
3. 閉じますが、これは私のソリューションよりもメタデータの柔軟性を制限します。メタデータのキーと値がかなり基本的なものであれば、動作する可能性があります。
4. これがどういう意味なのかよくわかりません-私が提案しているのと同じですか、それとも何か他のものですか？
5. 構造化されたXMLをRDBMSに保存するのは好きではありません-このIMHOを実行すると、RDBMSのパワーのほとんどが失われます。

それが私の考えです-このようなシステムを設計したことはありませんが、これらのスキームのいくつかを使用した商用システムを扱ってきました。

Answer 2

CouchDB を使用しない理由このタイプの要件に対応するように設計されています。

それがオプションではない場合は、LuaまたはJSon（＃5オプションごと）をメタデータ記述子として使用することを検討してください。

Answer 3

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