Originally aired on
February 24th, 2016
Traditional relational databases like MySQL or Postgres are really good at providing many solutions to the problem of persisting state. But these types of database are really horrible at querying highly connected models in an efficient way.
Graph databases like Neo4j and OrientDB excel at highly connected data. In fact, graph technologies are the backbone of social networks like Facebook and Twitter. We discuss how to think about our data using the graph model and what tools we can use in our PHP projects to interface with them. We also discuss the considerations we'll need to make when deciding whether or not to use a graph database in our next project.
Graph DBs don't usually use SQL. The most common query languages are:
I want to be able to allow a user to subscribe (edge) to an event (node), but manage what sort of notifications are associated with that subscription. Should I use multiple edges between the user and node (an edge for each notification), or one edge (subscribe) with multiple properties (notifications) associated with that edge?
The panel offer their opinions on both solutions and also propose another solution: represent each notification as a node (rather than en edge or an edge property) and create edges between the user and the notification nodes.
Ultimately, it depends on how you want to query it.
Thank you, Adam Engebretson for your contributions to the Laravel community. A $50 Amazon gift card from Laracasts is on its way to you.
Thank you Chris Shaw for authoring the show notes for this episode!
If you'd like to contribute show notes and totally get credit for it, check out the show-notes repo!