For some reason, some mutuals got me thinking about smoking
Memory: working as a teen, I knew a guy who was 100% sure that it was the glue in cigarette papers that caused cancer, not the tobacco. He smoked natural tobacco leaf-wrapped cigars, thought he was all good
at the shop where I worked, there was a 90-yr old guy who walked with a cane. Was the spitting image of William S. Burroughs. Every day, he came in and got his usual, 2 packs of Lucky Strikes unfiltered
when you're a teenage smoker yourself, a 90-yr old with a 2-pack a day Lucky Strikes habit is like a hero, but even then I knew he was more lucky than "right"
This only shows part of the picture; with recursive CTEs in #SQL I believe it is the case that:
- You can constrain max recursion, but not minimum without writing extra code
Contrast to cypher:
MATCH (e:Employee)-[:REPORTS_TO*3..5]->(:Employee)
recursive CTEs are a good example of "implementing a graph abstraction on top of something else". Namely the employee table represents a bunch of node instances; the managerID is a relationship, and the CTE implements a graph traversal.
Example thread on how to load #JSON into #Neo4j Aura -- working up from simple to more complex. Let's use the .@TheHackersNews public API to load a mini-feed of stories.
First: head endpoint with best stories, and simplest JSON load:
the apoc.load.json call always returns "value" with whatever came back. HackerNews is sending results, an array of post IDs.
We can extract out just the post IDs with a bit of extra cypher like this. Nice clean array of long values.
One step further; now we will UNWIND the array, turning the nested array into each individual item, and then build the URL we'll ask of HackerNews to get the detail of each story. This is how we build URLs one by one; we just take the story ID and concat it into a string URL
Real developer problem that gets solved by #graph. Today's thread: JSON document nesting
🧵
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
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