2016-08-22 12 views
0

ノードとリレーションのグラフに時間関連の情報を保存したい。理想的には、プログラミング言語では、ソートされたマップを使用して、キーとして日付と属性として関連付けられた各値(たとえば価格)を関連付けます。 「支払われた」というマップと、「2016/02/12」、「2016/03/21」、5; .....のようなエントリを持つPERSON 同じことはレストランとの関係PERSONにはいつ、どのくらいの金額があるかを知るために「支払われた」という同じマップがあります。Neo4Jに関連するものを保存する

Neo4Jでは、わかりません。私は2つの配列をプロパティとして格納することができました。日付と価格は1つですが、問題は順序を尊重して挿入する方法です(最後に挿入したものは新しいものではありません)。 XとYの間に日付があります。これはCypherでは私にとっては些細なことではありません。

もう一つのアイデアは、日付ごとに1つのリレーションを作成することです。これにより、グラフは同じノード間の関係が膨大になりますが、照会する方が簡単です。これはノードの問題を解決するものではなく、リレーションシップのみを解決します。

私はここで別の解決策を見ました:各日付のプロパティを追加してください。 Person.2016/02/12 = 2、Person.2016/03/21 = 5など... Neo4Jはこのタイプのプロパティの名前付けを受け入れず、これをクエリする方法がわかりません日付。

ご協力いただければ幸いです。

ありがとうございます!

--edit-- 実際には、多くの支払いノード(基本的には1日、1日、1年間、数十万ノードのノード)が必要になります。支払いノードを追加するとグラフが大きくなりますロット。実際には、私はJavaなどで挿入を行うことができたので、基本的に私は常に2つの配列を自分のノード/リレーションでソートします...私がグラフを照会できるかどうかは分かりません> = date1となる配列 "dates"のインデックスと配列 "dates"のエントリのインデックス< = date2

答えて

0

プロパティに複数の値が必要な場合は、常にノードを導入することができます代わりにpaid性を有するのは、Paymentノードにリンクすることができます。

CREATE (p:Person {uid: 1}) 
# Add multiple payments, that can be queried by date 
CREATE (p)-[:IS_PAID {date: "2016-02-12"}]->(:Payment {amount: 2}) 
CREATE (p)-[:IS_PAID {date: "2016-03-21"}]->(:Payment {amount: 5}) 

また、日付(例えば、タイムスタンプ)に数値を使用することができます。あなたは、簡単にそれを照会することができます

MATCH (p:Person {uid: 1})-[rel:IS_PAID]->(p:Payment) 
WHERE "2016-02-01" <= rel.date < "2016-03-01" 
RETURN sum(p.amount) AS total 

をあなたはまた、ハイパーグラフを表す、ちょうど別の支払データが含まれている関係を「複製」の作成を避けるために、関係のコンテキストで同様のことを行うことができます。

CREATE (p:Person {uid: 1}), (r:Restaurant {uid: 1}) 
# Create an archetype of a meal (a person in a restaurant) 
CREATE (p)-[:HAS_MEAL]->(m:Meal)<-[:SERVES_MEAL]-(r) 
# Add multiple payments for actual meals 
CREATE (m)-[:IS_PAID {date: "2016-02-12"}]->(:Payment {amount: 2}) 
CREATE (m)-[:IS_PAID {date: "2016-03-21"}]->(:Payment {amount: 5}) 

1つのリレーションシップではなく2つのリレーションシップと1つのノードが得られますが、すべての支払いで再利用でき、PersonとRestaurantの間に1つのパスを保持します。支払い。

それは前のノードと同じように簡単に照会しています:

  • 月に特定のレストランでは、人によって支払わ総:

    MATCH (p:Person {uid: 1}), (r:Restaurant {uid: 1}) 
    MATCH (p)-[:HAS_MEAL]->(m:Meal)<-[:SERVES_MEAL]-(r) 
    MATCH (m)-[rel:IS_PAID]->(p) 
    WHERE "2016-02-01" <= r.date < "2016-03-01" 
    RETURN sum(p.amount) AS total 
    
  • 月に人が支払った合計、レストラン1台あたり:

    MATCH (p:Person {uid: 1}) 
    MATCH (p)-[:HAS_MEAL]->(m:Meal)<-[:SERVES_MEAL]-(r:Restaurant) 
    MATCH (m)-[rel:IS_PAID]->(p:Payment) 
    WHERE "2016-02-01" <= r.date < "2016-03-01" 
    RETURN r, sum(p.amount) AS total 
    
  • 2月中の人:

    MATCH (p:Person {uid: 1}) 
    MATCH (p)-[:HAS_MEAL]->(m:Meal)<-[:SERVES_MEAL]-(r:Restaurant) 
    MATCH (m)-[rel:IS_PAID]->(:Payment) 
    WHERE "2016-02-01" <= r.date < "2016-03-01" 
    RETURN DISTINCT r 
    
  • 2名が両方訪問したレストラン:

    MATCH (p1:Person {uid: 1}), (p2:Person {uid: 2}) 
    MATCH (p1)-[:HAS_MEAL]->(:Meal)<-[:SERVES_MEAL]-(r:Restaurant), 
         (p2)-[:HAS_MEAL]->(:Meal)<-[:SERVES_MEAL]-(r) 
    RETURN r 
    
  • などは、あなたの答えフランクため

+0

おかげで、それは私がやったかについての解決策であります私はそれがレストランの例のために非常にエレガントだと言わなければならないが、私のアプリケーションは正確にこれではないと私は多くの支払いノードが必要になります(基本的に1日1日、毎日、数十年間ndsのノード)、これは私のグラフが大きくなるようにします。私は本当にプロパティとしてそれを保持したいと思います。 –

+0

まだ、グラフデータベースであり、ノードや関係を管理する方法を知っています。しかし、ええ、私はあなたのユースケースを知らない、ちょうどあなたの短い例に基づいていくつかのクエリを想像した。あまりにも多くのデータをロードするのを避けるために、早期にフィルタリングするという利点があります。一方、1つのノードに多くのプロパティを配置すると、必要な場合でもそうでなくてもロードできます。 –

関連する問題