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

Question

ドキュメントストレージのソリューションを構築しています。ドキュメントやタイトルのような基本データから関連イベントの日付まで、または各国の規制に準拠するために多数の追加メタデータを保存する必要があります。処分と分類のルール。

私はソリューションのさまざまな種類を見てきましたが、どれも私を説得しない：新しいメタデータスロットが追加されます（そう、彼らは文書に関連付けられたメタデータと同じ数の列を持っている）とき、列に成長

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

関連するメタデータで検索するためのパラレルフルテキストインデックス（Lucene.Net？Other？）を提供しています（すべてを「検索可能」にする必要はありません）。

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

Answer 1

表1：文書情報（PKは、文書IDである）

表2：メタデータ定義（PKであるメタデータ定義ID）

表3：文書ID、メタデータdefintionのID、メタデータ値

これの最大の欠点は、単一のタイプ（おそらくvarchar）を持たなければならないか、n個のカラム（nは保存したいデータタイプの数）を持つ必要があることです。メタデータ定義表の列を使用して、表3のどの列から値を取り出すかを識別します。記載されている5つのソリューションの

私の意見：

1. 成長の表は、（あなたが/欲しいnull非許容のメタデータ値を必要とする場合は特に）の痛みで、ラインの下の問題を引き起こす可能性があります。
2. I 嫌い「一般的な列」は熱狂的ですが（人気がありますが）。
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のリファレンス実装です。試してみてください。