couch dbとSQLサーバーを並べて使用

Question

現在、私たちのマスタアプリケーションデータベースであるきれいなリレーショナルSQLサーバー2008データベースがあります。我々は、類似しているが同一ではない文書を扱うことができる、よりスキーマレスなXMLデータ型を使用する既存の文書保管メカニズムを改善することを検討しており、couchdbが適切と考える。

考えられるのは、ドキュメントの一般的なメタデータをSQL Server内に格納して表示/集約/レポートを容易にすることができますが、実際のドキュメントは微妙な差異を処理するためにソファに格納されます。アイデアは、2つの異なる技術を最大限に活用することです。

たとえば、作成されたステータス、タイプ、関連者、作成日はすべてすべてのドキュメントで共通でsqlに格納されますが、電子メールと文字（明らかに異なるフィールド）はソファに格納できます。

次に、sqlによって照会できるすべてのタイプのドキュメント（何千ものドキュメント）についてドキュメントグリッドを表示できますが、ユーザーが表示するように要求すると、ドキュメントの表示はソファからデータを取得します。

いくつかのドキュメントタイプは、ドキュメント自体であるテンプレート（メールマージ/検索と置き換えと考える）から生成されることがあります。

アプリケーション層は、IOCのためのasp.net 4.5、C＃の、リポジトリパターン、ウィンザーでは、JavaScript

だから、質問に...

はを最大限に活用するために賢明な方法このアプローチです2つの異なるデータストレージのパラダイム？

「問題に最も適切な技術を使用する」という欲求の中で、私たちはプログラミングの生活を不必要に複雑にしていますか？

誰かが似たような試みを経験したことがありますか？その場合、どうしましたか？

Answer 1

ドキュメントに2つの異なるフォーマットを使用することは、珍しいことではありません。検索可能なアスペクトとメタデータのためのものと、プレゼンテーションのためのものです。より一般的な方法でそれを見てみると

、アプローチは、我々はデンマーク王立図書館で開発され、惑星EUプロジェクトにプッシュされたものと似ています：

http://www.researchgate.net/publication/221176211_Archive_Design_Based_on_Planets_Inspired_Logical_Object_Model

ここで論じて別の紙ですより一般的な方法でこのアプローチ： "Opening Schrödingers Library"

目標はアーカイブしていました。アーカイブや保存のために文書を変換するとき、元の文書の属性、形式、外観、内容などを保存するすべての面で優れた保存形式は存在しませんでした。解決策：いくつかの形式に変換し、高度なデジタルオブジェクトを使用して変換を追跡し、元のどの部分がどの変換で最もよく保存されているかを確認します。

私の意見では、このアプローチは理論的かつ事実上健全です。

実際の問題：おそらくドキュメントのさまざまな部分を追跡するデジタルオブジェクトが必要です。それが1つのシステムだけで起こるかどうか（そしてそのどちらか）この面ではSQLserverを使用しているようですが、それは賢明です。

実際に私たちが論文で説明したオブジェクトモデルを実装しましたが、私は彼らがまだそれを使用していると聞きました。