のレベルに基づいて、グラフデータベースを設計する方法、等例： - 側にのNeo4j - タイプおよび/または作業環境、家族、コミュニティ、例えば関係
は、BはボスでありますB側、Aは従属です。
C側では、Dは教師 - D側ではCです。
E側では、Fは父です - F側ではEは子です。
E側では、Dは教師 - D側ではEが生徒です。
上司、部下、教師、学生、父親、子供などの属性は、いつでも増加、変更、削除できます。
「リレーション」を表す3つのリレーションシップタイプを使用できます。たとえば、REPORTS_TO、HAS_STUDENT、HAS_CHILD：
(a)-[:REPORTS_TO]->(b)
(d)-[:HAS_STUDENT]->(c)
(f)-[:HAS_CHILD]->(e)
(d)-[:HAS_STUDENT]->(e)
（タイプHAS_STUDENTの例えば、）のNeo4jの関係は、（教師のノードからの学生のノードに例えば、）特定の方向を使用して作成されなければならないことは事実ですがクエリを作成するときに、反対方向（またはどちらか一方）に簡単に（かつ効率的に）横断することができます。
私はそれを持っています。しかし、これはどうですか？関係は1つのタイプのエッジ、例えば（c） - [：RELATES_TO {"：" student "、"：teacher "}]→（d）で十分でなければなりません。その場合、データセットプロパティ（param： "string/words"）を持つノード、つまり関係のないノードを参照する引数で、 "as"および "to"プロパティの値を置き換える方法。 –
DBのトラバースは、1つのリレーションシップタイプしか持たない場合は非常に効率が悪くなります。 Neo4jは、すべての候補ノードのすべての関係を反復して、必要な「as」および「to」値を持つノードを見つける必要があります。あなたは間違いなくそれを避けたい。おそらくあなたはあなたの質問にあなたのユースケースが何であるかを説明しなければならないでしょう、それは明らかではありません。 – cybersam
私はまだ関係的思考の影響を受けているようです。ごめんなさい。ありがとう。あなたの提案はとても啓発的です。私はまず自分の考え方を正当化しようとします。 –