0
votes

I'm trying to figure out how to best model

User -> Role -> Permission -> Content in a graph database for a CMS I'm attempting to build.

My current approach is to have User and Role as nodes and then each type of permission as a separate edge between Role and Content.

I did however also read an article https://medium.com/@gadberger/role-based-access-control-using-a-graph-database-2573debb685e that suggests an edge between Role and Content with properties for each permission.

Finally there is http://www.charlesnurse.com/post/Look-Mom-NoSQL-10-An-Introduction-to-Graph-Databases that suggests having User, Role, Permission and Content as nodes, which basically only differs from my current solution by having Permission as a node rather than being and edge.

I'm a little confused whether to model permissions as

  • a node
  • an edge with all separate permissions as properties on that edge
  • a separate edge for each individual permission

What are the pros / cons of each and what would best fit in the context of a CMS?

I'm using ArangoDB.

1

1 Answers

0
votes

I'm not sure I can fully answer these questions for you, aside from some guidance based on node/edge differences.

The main feature of a node is that you can link other nodes to it with an edge. You cannot create links between edges.

Given that, I think the implementation is up to you, based on your data, understanding of the graph, and how much management of individual permissions you want to do (changing a single node vs. lots of edges).

ArangoDB allows you to define multiple "named" graphs over the same nodes, which could be handy. For instance, you could have one graph that defines correlated documents and another that defines permissions. The two graphs could be completely unrelated and limiting the "named graph" to a specific purpose might speed traversal significantly (YMMV).