Sometimes the easiest way to learn a new technology is to compare it to a technology you already know. Such is the case with Graph databases. When you hear about them or watch videos about them elsewhere they talk as if they can cure cancer and give you a foot massage all at the same time.
In an academic setting, graph databases can do some fun & esoteric things. But in the real world, where greenfield may never be on the menu, a hybrid RDBMS & graph makes far more sense. Letting the relational system do its thing while tapping into the value & capabilities of a graph in bite-sized chunks without any need for full adoption, big migrations, or system concessions.
Getting started
To that end, I have written a small sample that solves the same problem using relational tables (the part you probably already understand) and then graph tables using SQL graph. A kind of Rosetta Stone for graph databases in terms SQL developers can understand. The solution using tables.
The solution using graph.
What is the common question, you ask? It is to design a system which stores enough data on customers, products, sales, and recommendations to provide to a customer a recommendation of a new products. I know it seems simple, but a complicated sample sort of messes up the whole point of the exercise.
Find the code here: graph.ipynb (github.com)