Was on reading this
My question is on performance on Relationship creation.
Once we go with the approach of having RelationshipType then i would expect to have good performance since RelationshipType will not be created(if already exist).
On other side with just ONE RelationshipType and have different value of a property, it needs to create property data (irrespective weather its same data or different) so it should lag in performance.
I find it more helpful to think about how I'm going to use the graph. For example, if you're connecting a customer to a phone number and you record whether that phone number is a home number, a cell number, a work number, or a fax. Are you going to be running searches for specific kinds of phone number (ex: you only want to return cell numbers so you know that you can send a text) or do you just want to know whether there is a number, any number, associated with the customer (ex: you want to count the number of contact points you have for that customer).
Searching is faster by relationship that by property, so you'll want to optimize your graph model for that.
For most use cases, you only write to the database once, but query it many times. I suggest focusing on making queries as fast as possible.
in reply to your answer (in the context of scenario where write once read multiple times)....
performance is better with
'The multiple-relationship-types approach always outperforms the single-type-and-property approach,'. This is what from the URL (of the link mentioned above)
However coming to my original question (could be i have not expressed properly). What i was looking is... 'performance on write once'
case-1: if we go with having multiple relationship-type, i would expect high performance (since once the relationship type is created then its moment to point to that specific relationship-type
case-2: if we go with having 'property' on a single Relationship-type . then on each and every relationship , it will be data value (property on relationship) need to create. Irrespective same data is there or not .
I consulted with the developer who has done most of the graph database write operations for my department. He said the fewer operations you do against the database the faster the write process will go.
In the context of relationship properties vs relationship types, if you have all your attributes at initial write time then writing them as properties would be faster than writing each of them as a separate relationship type.
IE (in psudo code): Create relationship x with properties a, b, and c VS Create relationship a, create relationship b, create relationship c. The first would be a single write operation, the second would be 3 write operations.
However, if you have to merge each of the properties separately it would be a wash. IE (in psudo code) Create relationship x with property a, merge property b, merge property c VS create relationship a, create relationship b, create relationship c. Both versions are 3 write operations.
With that said, it seems the number of write operations needs to be optimized to the fewest possible while still resulting in the graph that lets you do what you need. The two following graph models will allow you to do different things, and which structure is best depends on your use case.
Hope that helps.