diff --git a/content/en/ch2.md b/content/en/ch2.md index de82bf8..00a706c 100644 --- a/content/en/ch2.md +++ b/content/en/ch2.md @@ -4,9 +4,6 @@ weight: 102 breadcrumbs: false --- - -# Chapter 2. Defining Nonfunctional Requirements - > *The Internet was done so well that most people think of it as a natural resource like the Pacific > Ocean, rather than something that was man-made. When was the last time a technology with a scale > like that was so error-free?* diff --git a/content/en/ch3.md b/content/en/ch3.md index 409528d..460714a 100644 --- a/content/en/ch3.md +++ b/content/en/ch3.md @@ -652,15 +652,14 @@ saying how many sharks you have sighted per month. In PostgreSQL you might expre this: ``` -SELECT date_trunc('month', observation_timestamp) AS observation_month, ![1](/fig/1.png) +SELECT date_trunc('month', observation_timestamp) AS observation_month, ❶ sum(num_animals) AS total_animals FROM observations WHERE family = 'Sharks' GROUP BY observation_month; ``` -[![1](/fig/1.png)](/en/ch3#co_data_models_and_query_languages_CO1-1) -: The `date_trunc('month', timestamp)` function determines the calendar month +❶ : The `date_trunc('month', timestamp)` function determines the calendar month containing `timestamp`, and returns another timestamp representing the beginning of that month. In other words, it rounds a timestamp down to the nearest month. @@ -701,8 +700,7 @@ sections where schema flexibility is beneficial. Relational-document hybrids are combination. > [!NOTE] -> Codd’s original description of the relational model -> [^3] actually allowed something similar to JSON +> Codd’s original description of the relational model [^3] actually allowed something similar to JSON > within a relational schema. He called it *nonsimple domains*. The idea was that a value in a row > doesn’t have to just be a primitive datatype like a number or a string, but it could also be a > nested relation (table)—so you can have an arbitrarily nested tree structure as a value, much like @@ -965,15 +963,15 @@ Cypher. ##### Example 3-6. The same query as [Example 3-5](/en/ch3#fig_cypher_query), written in SQL using recursive common table expressions -``` +```sql WITH RECURSIVE -- in_usa is the set of vertex IDs of all locations within the United States in_usa(vertex_id) AS ( SELECT vertex_id FROM vertices - WHERE label = 'Location' AND properties->>'name' = 'United States' ![1](/fig/1.png) + WHERE label = 'Location' AND properties->>'name' = 'United States' ❶ UNION - SELECT edges.tail_vertex FROM edges ![2](/fig/2.png) + SELECT edges.tail_vertex FROM edges ❷ JOIN in_usa ON edges.head_vertex = in_usa.vertex_id WHERE edges.label = 'within' ), @@ -981,7 +979,7 @@ WITH RECURSIVE -- in_europe is the set of vertex IDs of all locations within Europe in_europe(vertex_id) AS ( SELECT vertex_id FROM vertices - WHERE label = 'location' AND properties->>'name' = 'Europe' ![3](/fig/3.png) + WHERE label = 'location' AND properties->>'name' = 'Europe' ❸ UNION SELECT edges.tail_vertex FROM edges JOIN in_europe ON edges.head_vertex = in_europe.vertex_id @@ -989,14 +987,14 @@ WITH RECURSIVE ), -- born_in_usa is the set of vertex IDs of all people born in the US - born_in_usa(vertex_id) AS ( ![4](/fig/4.png) + born_in_usa(vertex_id) AS ( ❹ SELECT edges.tail_vertex FROM edges JOIN in_usa ON edges.head_vertex = in_usa.vertex_id WHERE edges.label = 'born_in' ), -- lives_in_europe is the set of vertex IDs of all people living in Europe - lives_in_europe(vertex_id) AS ( ![5](/fig/5.png) + lives_in_europe(vertex_id) AS ( ❺ SELECT edges.tail_vertex FROM edges JOIN in_europe ON edges.head_vertex = in_europe.vertex_id WHERE edges.label = 'lives_in' @@ -1005,31 +1003,25 @@ WITH RECURSIVE SELECT vertices.properties->>'name' FROM vertices -- join to find those people who were both born in the US *and* live in Europe -JOIN born_in_usa ON vertices.vertex_id = born_in_usa.vertex_id ![6](/fig/6.png) +JOIN born_in_usa ON vertices.vertex_id = born_in_usa.vertex_id ❻ JOIN lives_in_europe ON vertices.vertex_id = lives_in_europe.vertex_id; ``` -[![1](/fig/1.png)](/en/ch3#co_data_models_and_query_languages_CO2-1) -: First find the vertex whose `name` property has the value `"United States"`, and make it the first element of the set +❶: First find the vertex whose `name` property has the value `"United States"`, and make it the first element of the set of vertices `in_usa`. -[![2](/fig/2.png)](/en/ch3#co_data_models_and_query_languages_CO2-2) -: Follow all incoming `within` edges from vertices in the set `in_usa`, and add them to the same +❷: Follow all incoming `within` edges from vertices in the set `in_usa`, and add them to the same set, until all incoming `within` edges have been visited. -[![3](/fig/3.png)](/en/ch3#co_data_models_and_query_languages_CO2-3) -: Do the same starting with the vertex whose `name` property has the value `"Europe"`, and build up +❸: Do the same starting with the vertex whose `name` property has the value `"Europe"`, and build up the set of vertices `in_europe`. -[![4](/fig/4.png)](/en/ch3#co_data_models_and_query_languages_CO2-4) -: For each of the vertices in the set `in_usa`, follow incoming `born_in` edges to find people +❹: For each of the vertices in the set `in_usa`, follow incoming `born_in` edges to find people who were born in some place within the United States. -[![5](/fig/5.png)](/en/ch3#co_data_models_and_query_languages_CO2-5) -: Similarly, for each of the vertices in the set `in_europe`, follow incoming `lives_in` edges to find people who live in Europe. +❺: Similarly, for each of the vertices in the set `in_europe`, follow incoming `lives_in` edges to find people who live in Europe. -[![6](/fig/6.png)](/en/ch3#co_data_models_and_query_languages_CO2-6) -: Finally, intersect the set of people born in the USA with the set of people living in Europe, by +❻: Finally, intersect the set of people born in the USA with the set of people living in Europe, by joining them. The fact that a 4-line Cypher query requires 31 lines in SQL shows how much of a difference the diff --git a/content/en/ch4.md b/content/en/ch4.md index 6f91612..5a365ce 100644 --- a/content/en/ch4.md +++ b/content/en/ch4.md @@ -1345,10 +1345,6 @@ documentation for the database of your choice. ### References - - - - [^1]: Nikolay Samokhvalov. [How partial, covering, and multicolumn indexes may slow down UPDATEs in PostgreSQL](https://postgres.ai/blog/20211029-how-partial-and-covering-indexes-affect-update-performance-in-postgresql). *postgres.ai*, October 2021. Archived at [perma.cc/PBK3-F4G9](https://perma.cc/PBK3-F4G9) [^2]: Goetz Graefe. [Modern B-Tree Techniques](https://w6113.github.io/files/papers/btreesurvey-graefe.pdf). *Foundations and Trends in Databases*, volume 3, issue 4, pages 203–402, August 2011. [doi:10.1561/1900000028](https://doi.org/10.1561/1900000028) [^3]: Evan Jones. [Why databases use ordered indexes but programming uses hash tables](https://www.evanjones.ca/ordered-vs-unordered-indexes.html). *evanjones.ca*, December 2019. Archived at [perma.cc/NJX8-3ZZD](https://perma.cc/NJX8-3ZZD) diff --git a/content/en/ch5.md b/content/en/ch5.md index b6b880b..04772af 100644 --- a/content/en/ch5.md +++ b/content/en/ch5.md @@ -1199,8 +1199,6 @@ quite achievable. May your application’s evolution be rapid and your deploymen ### References - - [^1]: [CWE-502: Deserialization of Untrusted Data](https://cwe.mitre.org/data/definitions/502.html). Common Weakness Enumeration, *cwe.mitre.org*, July 2006. Archived at [perma.cc/26EU-UK9Y](https://perma.cc/26EU-UK9Y) [^2]: Steve Breen. [What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability](https://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/). *foxglovesecurity.com*, November 2015. Archived at [perma.cc/9U97-UVVD](https://perma.cc/9U97-UVVD) [^3]: Patrick McKenzie. [What the Rails Security Issue Means for Your Startup](https://www.kalzumeus.com/2013/01/31/what-the-rails-security-issue-means-for-your-startup/). *kalzumeus.com*, January 2013. Archived at [perma.cc/2MBJ-7PZ6](https://perma.cc/2MBJ-7PZ6) diff --git a/content/en/ch7.md b/content/en/ch7.md index 0f2399a..6e0ec6b 100644 --- a/content/en/ch7.md +++ b/content/en/ch7.md @@ -781,7 +781,6 @@ that question in the following chapters. ### References - [^1]: Claire Giordano. [Understanding partitioning and sharding in Postgres and Citus](https://www.citusdata.com/blog/2023/08/04/understanding-partitioning-and-sharding-in-postgres-and-citus/). *citusdata.com*, August 2023. Archived at [perma.cc/8BTK-8959](https://perma.cc/8BTK-8959) [^2]: Brandur Leach. [Partitioning in Postgres, 2022 edition](https://brandur.org/fragments/postgres-partitioning-2022). *brandur.org*, October 2022. Archived at [perma.cc/Z5LE-6AKX](https://perma.cc/Z5LE-6AKX) [^3]: Raph Koster. [Database “sharding” came from UO?](https://www.raphkoster.com/2009/01/08/database-sharding-came-from-uo/) *raphkoster.com*, January 2009. Archived at [perma.cc/4N9U-5KYF](https://perma.cc/4N9U-5KYF) diff --git a/content/en/ch8.md b/content/en/ch8.md index ea1ffca..50ddce0 100644 --- a/content/en/ch8.md +++ b/content/en/ch8.md @@ -2313,9 +2313,6 @@ is used. ### References - - - [^1]: Steven J. Murdoch. [What went wrong with Horizon: learning from the Post Office Trial](https://www.benthamsgaze.org/2021/07/15/what-went-wrong-with-horizon-learning-from-the-post-office-trial/). *benthamsgaze.org*, July 2021. Archived at [perma.cc/CNM4-553F](https://perma.cc/CNM4-553F) [^2]: Donald D. Chamberlin, Morton M. Astrahan, Michael W. Blasgen, James N. Gray, W. Frank King, Bruce G. Lindsay, Raymond Lorie, James W. Mehl, Thomas G. Price, Franco Putzolu, Patricia Griffiths Selinger, Mario Schkolnick, Donald R. Slutz, Irving L. Traiger, Bradford W. Wade, and Robert A. Yost. [A History and Evaluation of System R](https://dsf.berkeley.edu/cs262/2005/SystemR.pdf). *Communications of the ACM*, volume 24, issue 10, pages 632–646, October 1981. [doi:10.1145/358769.358784](https://doi.org/10.1145/358769.358784) [^3]: Jim N. Gray, Raymond A. Lorie, Gianfranco R. Putzolu, and Irving L. Traiger. [Granularity of Locks and Degrees of Consistency in a Shared Data Base](https://citeseerx.ist.psu.edu/pdf/e127f0a6a912bb9150ecfe03c0ebf7fbc289a023). in *Modelling in Data Base Management Systems: Proceedings of the IFIP Working Conference on Modelling in Data Base Management Systems*, edited by G. M. Nijssen, pages 364–394, Elsevier/North Holland Publishing, 1976. Also in *Readings in Database Systems*, 4th edition, edited by Joseph M. Hellerstein and Michael Stonebraker, MIT Press, 2005. ISBN: 978-0-262-69314-1 diff --git a/content/en/part-i.md b/content/en/part-i.md index bd17fb6..1fc6445 100644 --- a/content/en/part-i.md +++ b/content/en/part-i.md @@ -31,3 +31,5 @@ Later, [Part II](/en/part-ii) will turn to the particular issues of distributed - [4. Storage and Retrieval](/en/ch4) - [5. Encoding and Evolution](/en/ch5) + +