Designing data-intensive applications chapter 2 part two notes/overview.
OK, in this article we're gonna be going over both Query languages (declarative and imperative). We will also be going over graph-like data models this is a continuation of chapter 2 part one where I went over both relational and document data models.
There are two main languages or language types for interacting with data, Declarative, and Imperative.
Imperative programming language requires going line by line in a specific order, and it's going to execute in that order every single time it runs; there isn't a lot of room for change, and when changes do occur, there can be a lot of implications that may not be necessarily thought about initially.
A declarative language is like SQL and even CSS Work a little bit differently they don't necessarily care what order things are happening in or what order they get the data they just understand that it needs to be done this gives you greater flexibility and more efficiency…
Graph-Like Data Models
Ok, so graph-like data models, I haven't started reading this chapter yet but I'm going to be talking through it as I go, a graph is just a series of nodes/Vertices that are connected to each other via edges. You can think of this as any sort of many to many connections, like your friends have friends and some of their friends are friends with you that would create a graph as well as how you would describe a map you have multiple ways to get to one destination and everything is interconnected.
A couple of examples out of the book. Social graphs, Vertices are people and edges, indicate which people know each other.
- The web graph, Vertices are webpages and edges, indicate HTML links to other pages.
- Road or rail networks, Vertices are junctions and edges representative at the railway lines between them.
Property graphs, In property graphs each of the vertexes or nodes consists of a unique identifier, a set of outgoing edges, a set of incoming edges, and a collection of properties. The outgoing and the incoming edges I would think of as an array and the collection of properties I would think of as a model.
Each of the edges also has a unique identifier and where is the edge begins where the edge ends and a label describing the relationship between the two and a collection of properties. This is almost verbatim out of designing data-intensive applications by Martin Kleppman.
I would highly recommend performing a depth-first search or a breadth-first search in order to really grasp what a graph data structure looks like.
So some additional sections in this chapter include the Cypher-query language(named after Cypher from the Matrix), graph queries in SQL, triple stores, SPARQL, and Datalog. Highly recommend doing a google. The syntax is pretty neat…. SQL *use-to have a WITH RECURSIVE function…