Let's take a step back. If I understand correctly the model should look
like this...
Nodes:
Account
Phone
Email
Ip
Relationships:
Account-[:has]->Phone
Account-[:has]->Email
Account-[:has]->Ip
Phone-[:has]->Account
Phone-[:has]->Email
Phone-[:has]->Ip
Ip-[:has]->Account
Ip-[:has]->Phone
Ip-[:has]->Email
On Tuesday, December 17, 2013 4:55:50 PM UTC-5, John Smith wrote:
>
> So I should create nodes as follows...
>
> CREATE (e1:Account {account: "12345"}), (e2:Phone {account:
> "555-555-5555"}), (e2:Email {email: "john.smith@gmail"}),
>
> (e1)-[:KNOWS]->(e2),(e1)-[:KNOWS]->(e3),(e2)-[:KNOWS]->(e1),(e2)-[:KNOWS]->(e3),(e3)-[:KNOWS]->(e1),(e3)-[:KNOWS]->(e2)
>
> But then for the new request that come sin how do I match it to the
> previous one?
>
>
>
>
> On Tuesday, December 17, 2013 4:24:10 PM UTC-5, Michael Hunger wrote:
>>
>> Yep, sounds like that.
>>
>> For some queries it might make sense to aggregate the primary phone /
>> email onto the account so you don't have to go the extra hop if you're just
>> reading (not checking or aggregating).
>>
>> Cheers
>>
>> Michael
>>
>> Am 17.12.2013 um 22:20 schrieb John Smith <[email protected]>:
>>
>> Hi thanks for the reply. Basically I wan to use this for on incoming
>> requests to my sytsem and see if funny things are going on. For instance
>> how many unique phones does a particular account have and vise versa.
>>
>> So if 1 account has 10 different phones then we know something funny is
>> happening.
>> Or if a phone has 30 different accounts then something funny also going
>> on.
>>
>> But typically 1 account should have 1 phone, 1 email
>>
>> In essence all nodes should be inter connected.
>> So accounts should know how many phones, emails, ip
>> Phones should know how many accounts, emails, ips
>> Emails should know how many accounts phones and ips
>> And Ips should know how many accounts, emails and phones.
>>
>>
>> On Sunday, December 15, 2013 5:07:35 PM UTC-5, Michael Hunger wrote:
>>>
>>> Yep,
>>>
>>> you can create unique nodes for emails, phone numbers and connect them
>>> to your accounts.
>>>
>>> So you can have multiple accounts connected to the phone# node with the
>>> same number which would actually be your inference.
>>>
>>> Of course you can also do a globaly query with aggregation and filtering
>>> to find duplicate entries.
>>>
>>> What would be your concrete use-case?
>>>
>>> Michael
>>>
>>> Am 13.12.2013 um 01:12 schrieb John Smith <[email protected]>:
>>>
>>> So say I have the following model....
>>>
>>> Account
>>> Email
>>> Phone
>>>
>>> Now I have the following data
>>>
>>> Account: 12345
>>> Email: john.smith@gmail
>>> Phone: 555-1234
>>>
>>> Account: 12345
>>> Email: you.me@yahoo
>>> Phone: 555-1234
>>>
>>> Account: 12346
>>> Email: you.me@yahoo
>>> Phone: 555-1235
>>>
>>> So we can deduce from the above that...
>>>
>>> Account: 12345 has 2 unique emails, 1 unique phone
>>> Account: 12346 has 1 unique email, 1 unique phone
>>> Email: john.smith@gmail has 1 unique account, 1 unique phone
>>> Email: you.me@yahoo has 2 unique accounts, 2 unique phones
>>> Phone: 555-1234 has 1 unique account, 2 unique emails
>>> Phone: 555-1235 has 1 unique account, 1 unique email
>>>
>>>
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Neo4j" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Neo4j" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
--
You received this message because you are subscribed to the Google Groups
"Neo4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
