Rules are everywhere. They define which legislation is applicable, which protocols to follow, which persons have access to a system, which documents to present to comply with regulations in a specific country. More often than not, rules are complex, as they depend on (a combination of) several characteristics.
When it comes to managing and evaluating rules, things easily get too complex to be handled in a relational database. You never know how deep the hierarchy is, you don’t know whether all branches of your logical hierarchy have the same depth, and, in order to be efficient you have to be sure that you only evaluate those rules that are necessary. A typical “graphy” usecase.
Having your rules in a graph database is not enough. You also need to be able to manage them (add or change rules / ports) and to evaluate them (which rules apply in my case?). It would also be nice to have an insight in why a certain rule applies or not, especially when your rules consist of several layers of nested ports.
In the example below, we have 5 rules that may or may not apply to each of the entities A to D, depending on the existence of Properties 1 to 4
For entity B, rules 1,2,4 and 5 apply. Rule 3 does not apply, because it needs both property 2 and 4 to exist
In this video, I show how rules can be changed, for instance adding another IF relationship, or change and AND port to an OR port.
Docker
Cloud