Title: After hearing&#x2F;reading about the negative experiences many people have had with upcoming graph databases, I am wary of jumping into a graph db. But almost any modern application has things that will be suited to a graph representation.<p>So I am considering a workaround to use a graph structure, but represent the underlying data in a reliable rdbms, in particular postgres.<p>The approach is:
1. Make two parent tables: node and edge. 
2. Make separate tables for all &quot;objects&quot; (like people, places, things, etc.) which would be inherited from node, so they would all have a unique node ID. 
3. Make separate tables inherited from edge which would be used to represent the many many relations. So each relation has an edge ID, and each table inherited from edge can be thought of as representing a specific kind of relation (like person lives in place, or person is friends with person).<p>One thing I have observed so far, is a large number of tables with few columns, but I think that lends itself to the advantage of  easy indexing. There can be a large number of individual queries from the front end, but I believe I can use views to make represent tables with more comprehensive info to reduce the number of queries.<p>What do you guys think of an approach like this? What am I missing, what is wrong with it? I haven&#x27;t come across this previously, and so am a bit nervous about the ramifications. Is someone else also doing this?
Upvote: