Комментарии 5
Многоуровневая структура запроса на SQL (как и в приведенном примере) вещь далеко не тривиальная. Как там будет срабатывать интерпретатор SQL при разборе вложенности и обработке данных зависит от реализации его в конкретной СУБД и качества нормализации БД. Здесь имеется ввиду время выполнения запроса как основной фактор. Обычно сложную вложенность операторов select рекомендуют разбивать на несколько запросов объединяя их в одной транзакции и комбинируя между собой операторы select и insert с использованием рабочих (временных) temp-таблиц. Выше сказанное в данном комментарии относится исключительно к общей теории языка SQL для манипулирования данными в реляционной БД, а НЕ как оценка приведенной в статье реализации на этом языке конкретного вычислительного примера.
Здесь имеется ввиду время выполнения запроса как основной фактор.
Так-то конкретно в этой статье про время исполнения не говорится ровно ничего (поскольку оно и так копеечное) - лишь приведена модель реализации конкретного алгоритма на SQL.
Многоуровневая структура запроса на SQL (как и в приведенном примере)
Тут ее в общем-то и нету. )) Реально многоуровневую можно увидеть, например, тут.
Как понял, смысл примеров заключается исключительно только в том, чтобы показать локальную возможность реализации алгоритмов вычислительного характера на конкретном диалекте языке SQL, хотя его основное назначение состоит в получении и обработке данных хранящихся в реляционной БД.
Да, собственно, это и написано во втором же абзаце.
Причем эта реализация, несмотря на вроде-бы-неподходящий профиль языка, обычно ничуть не проигрывает в понятности и краткости примерам на других ЯП: JavaScript, Python, Go, Rust.
SQL HowTo: немного математики (Advent of Code 2025, Day 1: Secret Entrance)