# Store a graph in relational database

As you are aware, a graph is the fundamental building block of a recommendation system. Graphs are data structures which typically store node and edges. Nodes are the real things (like books, shop items) and the edges (like the count, or number or repeated purchases)

As graphs can grow exponentially, it is very difficult, and expensive to store these complex data structures in memory.

So, the solution is to store these graphs in their minimal form in a relational database.

A simple table called 'edges' which contains node_a, node_b, is sufficient to store these datatypes, but it is not optmimized for retrival.

In order to return a sub-section of the entire graph, we would need to run many nested queries, as many as the depth to be returned.

However, the following image for the simple tree trasversing, provides the solution.

Now if we need to return the sub-tree, as long the ids represented in the edge table are the same used in the image above, we can simply retrieve the sub-tree of 'Fruit' by extracting all the node data from the 'edges' table from node_a > 2 and node_b < 11.

Hence, we need a new table to capture this information....

The original article can be read in full here:

http://www.sitepoint.com/hierarchical-data-database-2/