Building a graph database is time consuming. Why are you putting edge's children (person, place, friend) in a separate table instead of using a json field? Do you plan to query the person, place, friend table directly? You need to benchmark the different queries.
My understanding is that big5 and others do not use graphdb for all their stuff since they are not as good as rdbms to do queries with a single hop or JOIN. They embrace microservices and maintain a graphdb (in memory, persistent or distributed) to answer domain specific queries. That approach is similar to your schema except that graph queries run on a single node without superfluous network roundtrips.
It would be nice to be able to use a single database for all data related stuff to have atomic writes and simpler architecture. That's what multi-model databases are tackling have a look at OrientDB and ArangoDB [1].
Also, Tinkerpop, already mentioned in the thread, is a ready-to-scale graphdb with much love I recommend you have a look at Tales of the Tinkerpop [2].
Of course, JSON is a good way to store ad hoc, or new relations which haven't yet been structured. But for frequently occurring relations, I'm preferring separate tables instead of JSON for ease of querying and joins. If number of relationships are large, querying within a long JSON field is not the best approach.
Multi model db's are a good idea indeed. They were the first things I had considered, and extensively so - both OrientDB and ArangoDB. I came back to traditional solutions simply for practical reasons of maturity, and ease of finding professional support.
Someone here mentioned about a Tinkerpop implementation that uses Postgres as the storage engine, I think that might offer the best of both worlds, but I am yet to look into it.
The point about micro services is a really valid one. In principle, if the application is neatly split into a group of micro services, it would make things easier. This is something I am going to look into once the application has evolved somewhat - it is hard to make the split from the get-go, without knowing how it is going to be actually used - by the end user.
Comments
Building a graph database is time consuming. Why are you putting edge's children (person, place, friend) in a separate table instead of using a json field? Do you plan to query the person, place, friend table directly? You need to benchmark the different queries.
My understanding is that big5 and others do not use graphdb for all their stuff since they are not as good as rdbms to do queries with a single hop or JOIN. They embrace microservices and maintain a graphdb (in memory, persistent or distributed) to answer domain specific queries. That approach is similar to your schema except that graph queries run on a single node without superfluous network roundtrips.
It would be nice to be able to use a single database for all data related stuff to have atomic writes and simpler architecture. That's what multi-model databases are tackling have a look at OrientDB and ArangoDB [1].
Also, Tinkerpop, already mentioned in the thread, is a ready-to-scale graphdb with much love I recommend you have a look at Tales of the Tinkerpop [2].
[1] https://news.ycombinator.com/item?id=10180185
[2] https://news.ycombinator.com/item?id=10316140
Of course, JSON is a good way to store ad hoc, or new relations which haven't yet been structured. But for frequently occurring relations, I'm preferring separate tables instead of JSON for ease of querying and joins. If number of relationships are large, querying within a long JSON field is not the best approach.
Multi model db's are a good idea indeed. They were the first things I had considered, and extensively so - both OrientDB and ArangoDB. I came back to traditional solutions simply for practical reasons of maturity, and ease of finding professional support.
Someone here mentioned about a Tinkerpop implementation that uses Postgres as the storage engine, I think that might offer the best of both worlds, but I am yet to look into it.
The point about micro services is a really valid one. In principle, if the application is neatly split into a group of micro services, it would make things easier. This is something I am going to look into once the application has evolved somewhat - it is hard to make the split from the get-go, without knowing how it is going to be actually used - by the end user.