so it's common to have data elements like a "food" with some related information (here, it's "nutrition information"). When using a document database you basically have two choices:
- Store the two documents separately and lookup the other when needed
- Store them together
- Store the two documents separately and lookup the other when needed
- Store them together
Storing them together is great for efficient read operations. But it's bad for updates. If many foods share the same nutrition facts, and you need to update the facts, you have many updates to do to change one simple thing
because you duplicated data in sub-documents
because you duplicated data in sub-documents
what if you store them separately and then do lookups?
Well that makes updates easily, but then you pay the price on the reads
So to some extent, you're in a bit of a fix either way
Well that makes updates easily, but then you pay the price on the reads
So to some extent, you're in a bit of a fix either way
note that we're in #graph territory here because fundamentally the question is about *the relationship between two things* and that's where graphs excel: in the relationship management. So how would a graph do this?
(:Food)-[:HAS]->(:NutritionFacts)
(:Food)-[:HAS]->(:NutritionFacts)
If you need to update nutrition facts, you only update one element (all foods are connected to it). And of course reads are fast too because optimizing for rel traversal is the whole point of a graph database. Best of both worlds
the schema (i.e. what properties we store about foods and nutrition facts) can independently evolve; unlike in a JSON database where they'll tend to be coupled either by ID or by structure.
Why does this work? Because relationships are "pre-materialized lookups"
Why does this work? Because relationships are "pre-materialized lookups"
when you write a relationship to a graph database, it's similar to doing a lookup or a join because you had to know what to connect.
The difference is that the cost is paid one time, up-front, and never again. Contrast with paying every time you query, or every time you update
The difference is that the cost is paid one time, up-front, and never again. Contrast with paying every time you query, or every time you update
the meta-pattern here is that when the problems you're struggling with are *about the relationships* then #graph will likely help and when the problems are about dealing with large numbers of homogeneous not necessarily connected individuals, then graph probably isn't the fit
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
γ
