proofreading

lessons/01-welcome/B-what-is-sqlite.md

@@ -48,11 +48,10 @@ SQLite is unbelievably fast. Because we don't have replication or networks to de
 
 Yes and no. No replication is a tight bottleneck and no network access means you need more tools to use SQLite as a distributed database. So, yes, you can, but you need more tools.
 
-The startup I work at, [SQLite Cloud][cloud] is a paid service that can do this for you (with a generous free tier). [LiteFS][litefs] is an open-source way to do it yourself.
+There are several paid services that do SQLite in the cloud and they're all lovely. It's very viable to build a big production app on SQLite.
 
 [timeline]: https://sqlite.org/src/timeline
 [gh]: https://github.com/sqlite/sqlite?tab=readme-ov-file
 [diff]: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#devorg
 [most-used]: https://sqlite.org/mostdeployed.html
-[cloud]: https://sqlitecloud.io?ref=fem
 [litefs]: https://github.com/superfly/litefs

lessons/03-basic-sql/A-select.md

@@ -99,3 +99,5 @@ SELECT * FROM Artist ORDER BY name LIMIT 5;
 SELECT * FROM Artist ORDER BY name ASC LIMIT 5; -- Same as above query. ASC is implied if left out.
 SELECT * FROM Artist ORDER BY name DESC LIMIT 5;
 ```
+
+[sql]: https://frontendmasters.com/courses/sql/

lessons/03-basic-sql/C-tables.md

@@ -14,7 +14,7 @@ To see the table you created, run `.schema BandMember` in your psql instance to
 
 We now have a table. A table is the actual repository of data. Think of a database like a folder and a table like a spreadsheet. You can have many spreadsheets in a folder. Same with tables.
 
-We now have a table, ingredients. Our table has two fields in it, an incrementing ID and a string that is the the title of the ingredients. You can think of fields like columns in a spreadsheet.
+We now have a table, BandMember. Our table has two fields in it, an incrementing ID and a string that is the the name of the BandMember. You can think of fields like columns in a spreadsheet.
 
 A table contains records. A record can be thought of as a row in a spreadsheet. Every time we insert a new record into a table, we're adding another row to our spreadsheet.
 

lessons/04-intermediate-sql/A-relational-data.md

@@ -1,8 +1,8 @@
 So far we've done a one-to-one matching of records. We've used a record in a database to represent one item: one band member, band, etc.
 
-Now we're going to get into records that can relate to each other. Let's think about albums. A recipe has multiple ingredients. That **has** word is key here. It means there is a relationship. A single recipe has many ingredients. An ingredient can also be in many recipes. A tomato is both in pizza sauce and in a BLT. This is called a many-to-many relationship.
+Now we're going to get into records that can relate to each other. Let's think about albums. An album has multiple tracks. That **has** word is key here. It means there is a relationship. A single album has many tracks. This is a one-to-many relationship – one album has multiple tracks. Those tracks belong to that album. A track does not belong to multiple albums (in theory you could model this differently but let's say we choose to model it this way.)
 
-There are also one-to-many relationships, like imagine if we had multiple photos of each of our ingredients. A single ingredient will have five photos. And those photos will only will only belong to one ingredient. A photo of a green pepper doesn't make sense to belong to anything besides the green pepper ingredient.
+A band member can belong to multiple bands, and a band has multiple members. Dave Grohl has been in Nirvana, Foo Fighters, and Them Crooked Vultures. This kind of relationship is called many-to-many. Recipes and ingredients would be another good example of this. A recipe has many ingredients, and an ingredient can belong to many recipes.
 
 There can also exist one-to-one relationships but in general, you would just make those the same record altogether. You could split up the type and title into two tables, but why would you? Then you have a data sync problem. What if a band renames themselves? Ex: On a Friday → Radiohead, Prince → The Artist Formerly Known as Prince, The Quarrymen → The Beatles. Anyone who has ever tried to manually keep data in sync in two+ places knows eventually you will have issues.
 

lessons/05-build-a-project-with-nodejs-and-sqlite/B-sqlite3.md

@@ -92,3 +92,5 @@ db.get(
 Both are fine. Question marks rely on order, objection notation relies on names matching.
 
 This should be enough of an intro for you to write your sample app.
+
+[sqlite3]: https://github.com/TryGhost/node-sqlite3/wiki/API

lessons/06-what-is-unique-to-sqlite/C-views.md

@@ -52,6 +52,8 @@ ON
 
 Now go ahead and `SELECT * FROM easy_tracks LIMIT 15;` to see what we did. Cool, right? We can even start doing things like joins to this table as well. If you find yourself constantly doing the same joins (like we have this whole course) views can your friend.
 
-> SQLite does not materialized views like Postgres. That is to say, we cannot tell SQLite "run this query and store the results" like you can in Postgres. SQLite is always querying the live data underneath.
+> SQLite does not do materialized views like Postgres. That is to say, we cannot tell SQLite "run this query and store the results" like you can in Postgres. SQLite is always querying the live data underneath. [Click here to read more about materialized views][materialized].
 >
 > SQLite also does not support inserting into views like other databases do.
+
+[materialized]: https://sql.holt.courses/lessons/views/materialized-views

lessons/07-performance-and-search/B-indexes.md

@@ -49,4 +49,4 @@ Again, I have a hard time reading this. You can see that it refers to the index
 
 Okay so let's talk a little bit more about why you may not to index everything. I've heard the saying that indexes are like aspirin – they're a great help when you have a problem but if you use too many they become a problem.
 
-Every time you insert into a table that has indexes, it has to do some rebuilding of the indexes to accommodate this information. Likewise, if you delete, it has to move its nodes around its B-tree to keep it balanced. B-trees also take up space, and on large tables it can be non-trivial amounts of space. The trade-off here is that indexes help with reads but slow down updates, deletes, and inserts as well as take up space. In general I wait for a query to become a problem first before I try to index it, and even then I try to index only what I need to solve my problem. Pre-mature optimization generally a bad thing to do because as developers we're pretty bad at guessing what's going to go wrong.
+Every time you insert into a table that has indexes, it has to do some rebuilding of the indexes to accommodate this information. Likewise, if you delete, it has to move its nodes around its B-tree to keep it balanced. B-trees also take up space, and on large tables it can be non-trivial amounts of space. The trade-off here is that indexes help with reads but slow down updates, deletes, and inserts as well as take up space. In general I wait for a query to become a problem first before I try to index it, and even then I try to index only what I need to solve my problem. Pre-mature optimization generally is a bad thing to do because as developers we're pretty bad at guessing what's going to go wrong.

lessons/07-performance-and-search/C-full-text-search.md

@@ -36,7 +36,7 @@ CREATE VIRTUAL TABLE track_search USING FTS5(content="easy_tracks", content_rowi
 ```
 
 - We have to identify where the content is going to com from which will be a table. This table won't actually contain the rows but only the text searchable table that will have a rowid (which we identified as id; if you just call it rowid we don't have to tell it which rowid to use.)
-- We tell it what rows we want to include in full text search. Let's say we had producers in that table as well but we didn't want that to be searchable. No problem, you could write a query to select producers that have `MATCH 'black` and that still works fine! As long as it's in the view/table you're selecting from.
+- We tell it what rows we want to include in full text search. Let's say we had producers in that table as well but we didn't want that to be searchable. No problem, you could write a query to select producers that have `MATCH 'black'` and that still works fine! As long as it's in the view/table you're selecting from.
 - We're choosing to index the view we created earlier but you can definitely do it on normal tables as well.
 
 Okay, so because the table doesn't include the rows itself, we actually have to go populate it. We have to continually keep it up to date because [it does not automatically sync][sync] (unlike a view.)

lessons/09-scaling-sqlite/C-libsql.md

@@ -45,3 +45,4 @@ Run the query to add all the rows to the database. Once you've done that, [clone
 [repo]: https://github.com/btholt/sqlite-app-libsql
 [sqlite3]: https://github.com/libsql/libsql-node-sqlite3
 [sdk]: https://github.com/tursodatabase/libsql-js
+[turso]: https://turso.tech/