I extracted that section from our trusty episode transcript for your reading pleasure:
I think graphs are probably the simplest things to think about, really. People think about SQL tables - you have a row and you have some columns. Think of a graph as three columns where you have a subject, a predicate, and an object. If you put together a whole bunch of these things, you get a graph. A subject is essentially – think of it as an entity; a predicate is the relationship, and the object is either another entity, or a value.
The subject could be, let’s say, me. The relationship might be “lives in” and object might be “San Francisco.” Or it could be me - the name is Manish, and that’s sort of like a property. So you just put together a whole bunch of these facts, or triples, and you get a graph.
Then other people who live in San Francisco would have similar facts, and then you could run a graph query around “Hey, tell me all the people who live in San Francisco and who eat sushi.” So you pick up all the people who live in San Francisco, you intersect with people in the world who eat sushi - which are completely different facts. You didn’t create them as “This person lives in San Francisco AND eats sushi.” This is something that we’re doing on the fly. So you pick up all the people in San Francisco, you pick up all the people in the world who eat sushi, you intersect the two lists, and now you get people in San Francisco who eat sushi. Now you can take that result and say “Intersect it with all the people who have been to Japan.” You pick up another list of people who have been to Japan, intersect it with this, and now you get people who live in San Francisco, who eat sushi, and who have been to Japan.
So the power of graphs is really in these joins that you can do, coming from just very simple facts.
Thanks, Manish! 💚💚💚