MarkLogicでの親子関係の保存

Question

MarkLogicの場合（そしておそらくnoSQLの場合は？）、親子を1つのドキュメントとして保存するのが最善でしょうか？したがって、リレーショナル・ワールドから来た場合、正規化された親子表は非正規化され、単一の文書として保管される必要がありますか？

このデザインは検索の仕方に影響します（子レコードは親のコンテキスト内で常に検索されるため）。

Answer 1

子どもが複数の親を持つことができるかどうか（階層型ではなくグラフ型データなど）に依存するかもしれませんが、私の推論は階層型データの場合、自然な階層形式（XMLまたはJSONそのような）、最も理にかなっています。親子テーブル全体を1つのドキュメントとして保存するのではなく、元のツリーにレコードを展開し、ドキュメントとして保存することを意味します。

この

.. MarkLogicのように...彼らは内容と階層の周りの良い検索を提供場合は特に、すべてのNoSQLソリューションに適合しませんが、ドキュメントストアのカテゴリに分類されているもののためにうまく動作します。注：graph-タイプデータはMarkLogic内部でトリプルとして保存することができます。これによりSPARQLでクエリを照会し、その上で推論することができます。

HTH！

Answer 2

親子関係が「非正規化」ではなく、子どもが親に「結合」されていることではありません。

あなたが持っている関係の種類を考慮する必要があります。 UMLはさまざまな種類の関係の説明を提供します - Difference between association, aggregation and compositionを参照してください。

一般的に（例外が存在する）、私は、アソシエーションとアグリゲーションの関係は別々のドキュメント間にありますが、コンポジション関係は単一のドキュメントに「マージ」されると思います。

具体的な例 - 人は多くの人を知っており、人は多くの車両を所有することができます（集約、所有者は所有者が1人だけですが、ライフサイクルは自分のものです）。私は人と車の文書を作成しますが、名前の文書は作成しません - 私は人の文書にすべての名前を格納します。

私にとって、これはリレーショナルデータベースを上回る文書データベースの大きな利点です。後者では、どのような関係になっていても、別々のテーブルを作成する必要があります。ドキュメントデータベースでは、アプリケーションのニーズに最も合ったものを選択できます。非常に多くの場合、私の物理的な文書モデルは、アプリケーションの概念モデルに非常によく似ています。