Solution design leveraging Graph and Relational database types

Question

Is it viable to leverage both a graph db and a relational db at the same time for the same data sets? Does it even make sense to approach the solution this way?

Thinking is i use nodes and relationships to demonstrate the connections between entities, and relational db to store the deeper detail about the entity.

For example, purchasing cars from a garage in Graph DB would look like:

James (Node) 
    -> BOUGHT_FROM (Relationship) 
        -> Wild Mustangs (Garage)

The same data in relational db would be stored as

Person_Table

column | value
-------|------
name   | James
age    | 27
email  | j@email.com

Garage_Table

column     | value
----------|------
name       | Wild Mustangs 
location   | LA
garage_no  | TR 21234

Hopefully this example makes sense.

Answer 1

A graph DB and a relational DB can represent the same data:

• a tables is a set of relations between values of each columns in a row, that could be represented as nodes and edges of a (big) graph. A relational between tables adds edges that interconnect more nodes in the graph.

• a node in a graph can be represented as a row in a table, and edges with rows in another tables. (In your case, I’d miss a table BOUGHT_FROM that would store a person-identifier and a garage_no and probably some more information). Relational databases are routinely used to store graphs.

However, keeping both representations synchronous is a significant challenge:

• you need to find the appropriate mapping strategy to switch between both worlds. For exampe, are the nodes corresponding to the same values in two distinct rows (e.g. two person having the age 27) the same value node? or are two clone nodes?
• what if a column with two rows containing the same value is changed for one of those rows (e.g. one of the person is 28 while the other still is 27)? What is the algorithm to maintain the graph consistent?
• conversely, if you add a new node and an edge to an existing node, how are you going to map this in the relational database? is there a relationship that should be added ? is this a new column to be added to existing tables, etc...
• last but not the least, once you have the algorithm, think of concurrency and transactional processing, which must be kept in line as well.

So even if this is perhaps feasible, this is not desirable because if the complexity and the overhead.

Therefore chose the model that best suits your needs. And if you’re still hesitating, you could consider a CQRS inspired approach: use the RDBMS for the update commands and update the graph at the same time; use the graph db in read only mode for complex queries where the graph db would allow a better navigation. (if you consider the reverse, i.e updating the graph db and querying the rdbms, opt for a full graph db for both)