Jackrabbit や ModeShape のようなコンテンツリポジトリ( JSR28 )を評価しようとしていますが、どの問題が解決するのか理解できないことを告白する必要がありますそもそも、それがプロジェクトにとって良い選択であっても。どのケースが最適な解決策だと思いますか?サイズを除いて、リレーショナルデータベースと同じものではありませんか?どうして?実世界の例を指すための追加ポイント。
前もって感謝します。
JCRリポジトリはRDBMSとは異なります。これは、JCRリポジトリが以下を行うためです。
もちろん、これらの機能のすべてまたは一部を自分のアプリケーションで構築できますが、アプリの主な目的からさらに遠ざかる可能性があります。
これらの機能はどのようなアプリケーションに役立ちますか?コンテンツ管理システムは長い間リポジトリを使用しており、JCR(およびJackrabbit)は、異なるコンテンツリポジトリにアクセスするための共通の標準APIの必要性から本当に成長しました( JSR-170を参照してください および JSR-283 )。
別の例は、電子ファイル(多くの場合、紙の文書の画像)を管理し、検索とクエリを提供する文書管理システムです。 DMSは以前からリポジトリを使用しています。
アーティファクト管理システムは、リポジトリを使用して、デジタルアーティファクト(多くの場合ファイル)と追加情報(メタデータ)を管理できます。ここでは、ファイルと同じ場所にメタデータを保存できるため、JCRは優れた機能を発揮します。これらの追加プロパティを理解している人はそれらを見ることができ、気にしない人は見る必要はありません。 Artifactory は、JCRを使用するMavenリポジトリ実装です。 Webサービスアーティファクト、データサービスアーティファクト、およびテストアーティファクトを管理するためのリポジトリもあります。
ただし、JCRリポジトリはファイルを管理するためのものではありません。 JCRは、ノードの階層の単純な概念を使用します。ノードには、名前付きプロパティ(1つまたは複数の値)と子を含めることができます。許可されるプロパティと子ノードは、ノードタイプによって完全に決定され、必要に応じてノードごとに変更および混合できます。 JCRは、リポジトリ内のファイルやフォルダーを表すために使用されるものなど、一般的に必要な組み込みノードタイプを事前定義します。これらの組み込み型を再利用したり、拡張したり、独自の型を作成したりできます。多くの人は、ミックスインをほぼファセットまたはアスペクトとして使用することを提唱しています。そのため、ノードがファセットを処理する必要がある場合は、ノードにミックスインを追加するだけです。
JCRは、XML要素のリポジトリへのインポートを簡単にサポートするように設計されています。各要素はノードにマップされ、各属性は属性にマップされます。また、多くのものはXML(またはYAMLまたはJSON)を使用して表され、これらすべては簡単に表され、JCRリポジトリに格納できます。例として、構成情報(通常は複数のXMLファイルに格納される場合があります)を格納するJCRリポジトリを考えます。 JCRは、その情報をバージョン管理し、複数のプロセスからの情報へのアクセスを許可し、クエリと検索を有効にし、コンテンツが変更されたときにアプリケーションに通知できます。
JCRのいくつかの優れた概要と詳細と例があります。これらのいくつかは次のとおりです。