I was initially concerned about having strategy classes with different constructor signatures. However, after reviewing GoF’s Design Patterns and other resources, I realized it’s common practice to accommodate varying configurations. A factory class can handle this by instantiating the correct strategy with the appropriate parameters.
Disclaimer: This is not a summary of the chapter
In this chapter, overviews of data models and query languages that exist in the industry are provided.
SQL is the most popular data model in the industry, and it is based on the relational data model, which organizes data into relations (tables in SQL).
One of the issues with the relational model is impedance mismatch which means the disconnect between the structure of relation data and applications’ expression, which is object-oriented programming in most cases. When data is self-contained document and do not involve many-to-one/many-to-many relationships, the document model reduces the mismatch between the data expression and the application code. However, as the application evolves, it’s more likely that data will be interrelated. The document model can perform well when large parts of the document are fetched/used at the same time (self-contained).
One of the other most significant differences between the relational model and the document model is schema flexibility. The document model is often referred to as “schema-less,” thoguh “schema-on-read” is more appropriate because the code to read data expects some specific structure of data. (In my experience, having no validations/enforcement at the database level is full of potential bugs, but) its “schema-on-read” nature can benefit when
- There are many different types of objects, and it is not practicable to put each type of object in its own table.
- The structure of the data is determined by external systems over which you have no control and which may change at any time.
Also, the author points out
The moral of the story is that a NoSQL system may find itself accidentally reinventing SQL, albeit in disguise.
The author proceeds with the graph-like data model, whose paradigm was new to me. They provide some examples of Cypher, SPARQL, and Datalog. It is said that “If you can express a problem as a graph, you can solve the problem in no time,” but at the moment, I cannot come up with real-life examples. I will put the knowledge (?) in some parts of my brain.
I forgot to mention that the author touches the advantages of declarative languages such as SQL.
Udon 700 Yogurt 1000 Rice 300 Sushi 1500
Total 3500 kcal
MUST:
TODO: