私はグラフ データベースを初めて使用し、その約束された範囲とパワーに圧倒されました。アプリをデザインするときは、感情的なデザイン パターンと実際のパフォーマンス デザインを一致させることが非常に重要です。私を悩ませている質問の 1 つは、特定の情報をリレーション属性にするか、ノード属性にするかです。これがユースケースです。着信リレーション「service_provider」によって関連付けられているエンティティがあります。開始ノードは、終了ノードへのプロバイダーになります。現在、各サービスプロバイダーは、何らかの契約を介して顧客（または消費者）に関連付けられています。サービスの頻度、サービスごとのコスト、ノーショー料金など。これらの契約の詳細はサービスごとに異なりますが、属性は常に存在します。
したがって、私の質問は、これらのコントラクトがエンティティのペア (サービス プロバイダーとコンシューマー) に接続できる別のノードであるべきか、それとも関係自体の一部であるべきかということです。
私の感情的な感情はそれを関係の一部にすることであり、それが私の説明がそのような絵を描いた理由であることに注意してください. ただし、必ずしもそうであるとは限りません。私のアプローチを締めくくることができるように、あなたの意見を聞きたいです。
質問が間違った場所にあると思われる場合は、より良い場所を提案することを検討してください。
私はすでにドキュメントを参照しました @ docs.neo4j.org 推奨結果のブースト- すべてのドキュメントは、私が言及したことが可能な解決策であることを示しています。しかし、ここに懸念があります-例はリレーション属性についてはライトです-どちらのアプローチの長所と短所も実際には測定していません
同じの複数の関係... @ Stackoverflow - 実際には同じ質問ではありませんが、ユースケースに関連しています。
@bendaizer からの応答を参照すると、ここにパフォーマンスの質問があります。#1と#4(一部)を比較。コントラクトがサービス プロバイダーによって定義されていると仮定すると (少なくともほとんどの場合)、サービス プロバイダーがコントラクトを介してコンシューマーに接続できる唯一の方法です。そのため、契約に囲まれたサービスプロバイダーがあり、契約は消費者に接続されています。サービス プロバイダーで消費者を検索しようとすると、契約の余分なホップを実行する必要があります。#1 によると、同じ契約情報を関係プロパティに入れることができます。すべての契約が一意であると仮定すると、どちらがより良いパフォーマンスを期待できますか? そうする一方で、[「サービス プロバイダー X」のすべての顧客が 1 時間あたり 50 ドルの料金を支払っている - 1 時間あたり 50 ドルは契約情報の一部である] のような質問に答える能力を失いたくありません。