-1

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.

7
  • "Is it viable to leverage both a graph db and a relational db at the same time for the same data sets" - to solve which problem, precisely? Currently, this question looks to me like you have a solution looking for a problem.
    – Doc Brown
    Mar 7 at 16:59
  • Happy for a moderator to delete this question since its not seen as value by the community since i can't act on it. Christophe has given me valuable insight to the problem i'm facing and a direction to study in.
    – Aeseir
    Mar 8 at 8:26
  • Who says this question cannot not have value? If you got "valuable insight to the problem" you are facing, why do don't you to tell us about exactly this problem? What is your use case which requires "both a graph db and a relational db at the same time for the same data sets"? Tell us about the goal, ideally for a real-world problem of yours.
    – Doc Brown
    Mar 8 at 10:21
  • Probably because its been down voted number of times already, and its not a problem as it is more of a experiment. So for my experiment now I have a graph db representing current relationships, with detailed data and historical events in relational db.
    – Aeseir
    Mar 8 at 10:49
  • Reasonable questions getting downvotes on this site are no exception. What bothers me more are the many downvoters who seem to believe askers should be able to read their mind, because they leave absolutely no hint what's they think is wrong with the question. In this case, I downvoted, too, but I also told you about my expectation what I think is missing. In case you would edit your question and describe the problem you want to solve with this approach (even if it just an experiment), I would probably revoke my downvote (and maybe convert it into an upvote).
    – Doc Brown
    Mar 8 at 11:40
2

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. enter image description here

  • 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)

1
  • thank you for the great answer, and the associated food for thought. My thought process is once i clearly define the domain of graph v rdbms, i was thinking of having a service that manages the db matinenance for both rdbms and graph. I just have to be very clear and smart, to minimize some of the impacts mentioned.
    – Aeseir
    Mar 7 at 8:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.