SQL за одну статью: от «SELECT *» до оконных функций и сложных JOIN-ов

Колонки (поля) задают структуру...

Строки (записи) — это сами данные...

Вы пишете про SQL. Поэтому следовало бы сделать наоборот - использовать термины SQL как основные, а в скобках дать аналогию из Excel. И далее в статье использовать именно стандартные для SQL термины.

Foreign Key (Внешний ключ) — это колонка, которая ссылается на Primary Key другой таблицы.

Неверно.

Во-первых, это не поле (у вас написано "колонка"), а выражение. Которое может включать одно поле либо несколько полей и/или скалярных выражений от одного или нескольких полей и констант.

Во-вторых, ссылается он вовсе необязательно именно на первичный ключ. Ничто не мешает ссылаться на любое поле или выражение. Современные СУБД в подавляющем большинстве случаев, правда, требуют уникальности такого выражения (Постгресс, тег которого присвоен статье - требует), но даже это не догма, хотя и порождает неоднозначность. И если где-то и есть ограничение, что FK может ссылаться только и исключительно на PK, то это особенность конкретной СУБД.

DELETE vs TRUNCATE: в чем разница

Данное далее объяснение - неправильное. Разница в том, что первое - это DML, тогда как второе - DDL. Всё остальное - лишь следствия.

Логический порядок выполнения запроса

Похоже, и вы тоже это списали у кого-то. Маркер очень прост - никто не берёт на себя смелость написать самостоятельно, и в результате не указывает, где в этой схеме место выполнения оконных функций.

И отдельно следует рассматривать формальное место выполнения подзапросов - оно различается в зависимости от того, в какой кляузе подзапрос использован, а если во FROM, то является ли он LATERAL. Кроме того, нигде не указан достаточно важный факт, что функции, возвращающие наборы (а этого добра именно в Постгрессе хоть ложкой ешь, причём иной раз и неявно), работают как подзапросы (в подавляющем большинстве случаев - как LATERAL-подзапросы).

Важно: ORDER BY — довольно ресурсоемкая операция. Если вы сортируете миллион строк по текстовому полю без индексов, база может "задуматься" надолго. Но об индексах мы поговорим чуть позже.

Отдельные умельцы могут написать запрос так, что ни один индекс не поможет. В одном крупном интернет-магазине захотели показывать на каждой странице десять случайных товаров. Но что-то пошло не так, сайт стал сильно тормозить, так как довольно мощный сервер прилёг от нагрузки. Когда меня попросили посмотреть, я увидел там это:

SELECT * FROM goods ORDER BY rand() LIMIT 10;

Никакого кэширования результатов тоже не было, поэтому сервер честно каждый раз выполнял запрос.

Обычно JOIN-ы объясняют через диаграммы Венна (пересекающиеся круги).

Диаграммы Венна иллюстрируют операции объединения, пересечения и исключения с множествами. В SQL это операторы UNION, INTERSECT, EXCEPT: https://postgrespro.ru/docs/postgresql/current/sql-select#SQL-UNION
JOIN же - это декартово произведение. Я лично не в курсе, как декартово произведение отобразить графически.