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…

The best example I saw in the book to illustrate the difference between declarative and imperative was the author's decision to compare interacting with the DOM via JavaScript as opposed to using CSS selectors to change the style. To better explain imagine you wanted to change all P tags in an HTML document using JavaScript you create a function that is going to grab all of the P tag elements and attach the style you want to attach a post to a CSS selector that will search the entire document and just attract meaning to specified instructions.

OK, so one more time imperative versus declarative. Declarative is a very mechanical process like what she would use in order to alter CSS dynamically using JavaScript.Imperative is just throwing in a CSS class and labeling an element or just selecting the tag as is and letting everything just happened like it's on autopilot; the same with a select statement you don't care what order things come in You just watch your data so if we select all SQL is not going to care about what order gives you your data.

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…