Recommendation Engines: RDBMS and SQL, Versus Graph Database
Rodger Lepinsky, Oracle guru, takes on query performance with Neo4j’s Cypher Query Language versus SQL
For years, I’ve worked with Oracle, doing complex SQL. Recently I’ve been looking at the graph database, NEO4J.
Last night I was watching a NEO4J webinar about Graphs for Gaming.
It makes some interesting Cypher (NEO4J query language) queries for recommendation engines for a gaming company. The point being that certain tasks are much easier in Graph DB/Cypher than in RDBMS/SQL.
The more complex query was to take an individual gamer, Rik, and find other users/gamers, who:
- had worked at one the same companies as Rik
- spoke one of the same languages as Rik
- had NOT gamed with Rik yet
The 12 line Cypher query was:
rik-[ :SPEAKS ]-> language,
rik- [:PARTICIPATES ] -> session,
rik- [:WORKED_FOR|WORKS_FOR ] -> company,
person2- [:WORKED_FOR|WORKS_FOR ] -> company,
person2- [:SPEAKS ]-> language ,
person2- [:PARTICIPATES ] -> session ]
Not ( person2- [:PARTICIPATES ] -> session)
Return distinct person2.name
Having wrote complex queries for years, this didn’t seem too difficult for me. So how would you do it in SQL? Not having access to the actual tables, I could only imagine what the tables were. But the solution I envisioned was to use inline views, one of the incredible aspects of SQL, and an outer join.