Aggh, sure :) in case Edo Okati will tell us some more details about his business domain and what is valuable for his business (and what isn't), we'll have a possibility to continue this modeling exercise :)
But I think, from above we already are able to make two significant conclusions. 1. Being simple, easy to understand and valuable for business (already), in RDBMS this model would demand 14 (!) tables to implement (if not more). Think also about some JOINs required to operate it, and you'll see - for traditional data architect it is already a severe brain damage, but it is a simple exercise for beginner graph data architect :) 2. Implicit (indirect) relationships through indexed "foreign keys" - if done smart - may do good job for physical sharding of a big graph among different neo4j instances. For MDM and BigData implementations it may be valuable design pattern. I.e. for this exact case we can separate the catalog of physical and software inventory and the graph which represent the history of interactions between customers and their devices, networks and firmwares. For a system with millions of devices and millions of customers this might be pretty valuable. WBR, Andrii On Wednesday, November 19, 2014 3:29:31 AM UTC+2, Michael Hunger wrote: > > Thanks a lot Andrii for your insightful answer ! > > In the end it always depends on how important that aspect is for his > use-case, if it is a core concern or a "nice-to-have-additional-information" > > Michael > > On Tue, Nov 18, 2014 at 9:33 PM, Andrii Stesin <[email protected] > <javascript:>> wrote: > >> btw in case anyone cares, the first obvious real *property* of >> (unit:Device) node is it's factory serial number (omitted on the diagram). >> > -- 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/d/optout.
