2

現在、基本的に「アイテム」間のグラフを作成するアプリケーションに取り組んでいます。これらのアイテム間にはさまざまな種類のリンクがあると思いますが、特に双方向リンクをモデル化する方法を決定するのに苦労しています。

1. 例:

ItemB --isChildOf---> ItemA
ItemA --isMasterOf--> ItemB

同じものを次のようにモデル化できると思います。

例 2

ItemA <---> ItemB

私のデータベースモデルでは、現在、次のようにリンクをモデル化しています。

* sourceID
* targetID
* relationType (e.g. isMasterOf, isChildOf, maybe more...)

テーブルのフィールドとして方向も必要ですか? IMO の方向は sourceID と targetID によって暗黙的に定義されるため、これまでのところ別のフィールドとしては使用していません。

どのような状況で例 1 が必要になり、どのような場合に例 2 で十分かわかりません。例 1 は Twitter のようなもので、UserA は userB をフォローできますが、その逆はできないと思います。一方、私の意見では、Facebook は常に Example2 です。

私の質問が理にかなっていることを願っています。

4

1 に答える 1

3

可能な限り一般的で、単純なグラフモデリングの場合（1対多/多対1、多対多）で機能するソリューションが必要な場合は、リンクを（source_id、target_id）としてモデル化するだけです。別のリンクテーブルのペア。そうすればあなたは両方をすることができます

  • エッジペア（a.id、b.id）と（b.id、a.id）を使用して双方向リンクをモデル化し、方向に応じていずれかを使用して単方向リンクをモデル化します。
  • どのノードがソースで、どのノードがターゲットであるかを確認することで、エッジの方向を区別します。個別の方向フィールドを用意する必要はありません。

モデル化するグラフの種類に実際の制約がある特定のケースに対してエレガントなソリューションを作成する場合は、最初に決定する必要があります

  1. オブジェクト間で許可するリンクの種類：それらは常に単方向または双方向であるか、それとも両方を区別する必要がありますか
  2. 1つのオブジェクトが1つの親だけで多くの子を持つことができるツリーのような構造になるか、1つのオブジェクトが複数のエッジを行き来する可能性があるより一般的なグラフになるかどうか。

最初の点に関しては、すべてのリンクが同じ種類であることがわかっている場合、コード内でエッジ（source_id、target_id）とエッジ（target_id、source_id）を区別する必要はありません。どちらも、間のエッジを意味するからです。 2つのオブジェクト/ノード。

2番目のポイントに関しては、モデル化するグラフが木または森に似ている場合（すべてのオブジェクトに0または1の親と0からnの子があり、すべてのリンクは同じタイプ（単方向または双方向）です）、別のリンクテーブルで接続をモデル化する代わりに、オブジェクト自体にparent_idのようなものを追加することができます。

明らかに、エッジに他の属性（重みや方向以外のある種のタイプ属性など）が必要な場合は、それに応じてフィールドを追加する必要があります。その場合、エッジはノード間の単なるリンクではなく、実際のプロパティを持つオブジェクトになるため、いずれの場合も別のテーブルでエッジをモデル化するのが最も理にかなっています。

于 2012-10-17T11:23:42.593 に答える