Aligning relationships with use cases

One of the ways that you can model for query-ability and let your queries drive your model is by using the different relationship types that you can have between nodes for different use cases. Many great graph database models use multiple relationships between two of the same nodes for different use case scenarios.

One of the reasons why this a recommended best practice is actually applicable and of real use in practical development efforts is that the specialization tax, which is the price that you--as a developer--pay (mostly in terms of added model complexity) to introduce a specific relationship between two nodes for a specific use case, is in fact so low. There are no additional tables or schemas to be created, and to be even more specific, there are no additional joins to be computed. All that happens is that the graph traversals will use different paths to establish their course across the network stored in the database.

A key concept to be kept in mind when aligning relationships with use cases is the naming strategy for your relationship types. The general recommendation is to use as few generic names such as HAS_A or IS_PART_OF as possible, but to be more specific in these naming efforts.