Try to look at it that way: what isn't a relational table? Any data structure you can make is essentially a tuple of primitive elements. It may point to further data items, but still. Now, put equally shaped tuples in common tables, and you have a database.
Easily represented as a vertices-array and an edges-array. It's conventional to index the (directed) edges to optimize iteration over all edges from a given vertice. If you're being "sloppy", you can also represent edges as vector<vector<int>> (one array of destinations per source). This is more convenient but comes with the slight disadvantage that these arrays are physically separated (for example, you'll need two nested loops instead of only one to iterate over all edges).
At the same way that you can force everything in a deterministic or non deterministic Turing machine, depending from the problem.
But something that is just looking at data and relationships, akin to a relational database, while extremely powerful, can’t solve every problem in the world.
There are much better tools for that.
And they have something more than just data and relationships.
Of course you can force anything in a graph database. But then you have to make special collection objects to iterate over all Foo items in your process. I guess you'll also need some kind of garbage collector.
> Ironically graph databases are way better for describing relations than relational databases.
You can force pretty much every data structure that I know in a table.
That doesn’t mean that you can solve everything with a non Turing complete language.
So, unless I’m badly mistaken, you’ll need something more than data and relationships to solve everything.
