This is a good idea, but I do have some issues: RDBMS: > A subquery is generally a smaller resultset that can be used to power a select query in many ways. It

This is a good idea, but I do have some issues: RDBMS: > A subquery is generally a smaller resultset that can be used to power a select query in many ways. It can be used in a ‘where’ condition, can be used in place of join mostly where a join could be an overkill. In nearly all cases, a join will out-perform a subquery. If you don't need the joined table in the result, a semi-join is usually a good idea. Unrelated, in discussing MySQL configs, they link to the docs for 5.7, not 8.x. > Adaptive hash index: Supplements InnoDB’s B-Tree indexes with fast hash lookup tables like a cache. Slight performance penalty for misses, also adds maintenance overhead of updating it. IME, on high-traffic DBs the hit ratio is so low (not to mention the mutex locks) that it's faster to just disable the AHI. > [Joins are] powerful but also resource-intensive and makes scaling databases difficult. This is the cause of many slow performing queries when run at scale, and the solution is almost always to find ways to reduce the joins. This seems to imply that the answer to slow queries involving joins is to denormalize, which while sometimes valid, is definitely not the preferred solution. If you have a slow query, odds are high that something isn't properly indexed, or your schema design is poor to begin with. Bash scripts: * Inconsistently quoting variables * Exit status 2 * Seemingly being unaware of else if * Backticks instead of $() * Little to no discussion on pipes, and the vagaries they introduce