> A thing to think about: often there are many different graphs you can create to represent the same thing. Each graph representation can focus on or hide diffe

> A thing to think about: often there are many different graphs you can create to represent the same thing. Each graph representation can focus on or hide different aspects of the real system. This is usually the start of my argument in favour of representing data in a relational form. Any one graph is a projection of the domain. It privileges certain reads and writes over others. You inevitably find queries and updates that don't fit the graph's original shape and then suddenly it's a giant PITA to work with. If I build a project management system, I might have a graph that runs [Project] -> [Workers] -> [Timesheets]. If I want to calculate the sum of time on a particular project that's fairly efficient. But if I want to get the sum of time for a particular worker, I will need to traverse every project looking for them. In a relation form I'd have [Projects] n..n [Workers], [Workers] 1..n [Timesheets] and [Projects] 1..n [Timesheets]. When I need to sum in a project, I join on that. When I need to sum on a worker, I join on that. Neither is privileged over the other.