Михаил

Если Linux - то find + cat
Если Window - то Cygwin + find + cat

Технически вам никто не мешает так делать

Архитектурно - нужно смотреть по конкретному проекту.

Без проблем. Любую рекурсию можно представить в форме цикла.

Автоматически обновлять таблицу - это нужен триггер.

Можно сделать представление (VIEW) и тогда, при запросе данных из этого представления, каждый раз будет автоматически подсчитываться нужная вам сумма.

create table tbl (
        сol1 int,
  	col2 int
);

insert into tbl (col1, col2) values (1, 12), (1, 32), (2, 10), (2, 5), (3, 6), (3, 10);

CREATE VIEW tbl_sum AS SELECT tbl.*, SUM(tbl.col2) OVER (PARTITION BY tbl.col1) AS col3 FROM tbl;

SELECT * FROM tbl_sum;

https://sqlize.online/sql/mysql80/5b3c3e5b21a1083d...

Ну смотрите. У нас есть объем теста. Расход теста на блинчик прямо пропорционален площади оного блинчика. А количество блинчиков из одного и того же объема теста обратно пропорционально расходу теста на один блинчик. А площадь блинчика зависит от диаметра сковородки... Вроде дальше уже подсказывать некуда :)

Нужно указать сортировку в оконной функции. А ORDER BY запроса тогда можно делать по полю num.

SELECT u.id, u.avatar_path, u.rating, ROW_NUMBER() OVER (ORDER BY u.rating DESC) AS num
FROM users AS u
ORDER BY num ASC;

Учить разные языки программирования имеет смысл, поскольку каждый язык - это набор каких-то концепций. В свое время я использовал императивные языки (на работе - Java, в хобби-проектах - от C++ до PHP). И на этом этапе мне очень много дало знакомство с функциональными языками: Scala, Haskell. Я начал понимать много полезных концепций, таких как неизменяемость (immutable). А затем использовал их на основной работе (в частности по всему Java-коду щедрой рукой были рассыпаны модификаторы final). Так что не рассматривайте языки независимо друг от друга - этот для учебных задач, это для ИИ, этот для веба. Берите от каждого языка что-то хорошее и формируйте ваш собственный стиль программирования (пригодный, по сути, для любого языка).

Еще добавлю про такую тему как ИИ. В этой области начинать имеет смысл не с языка программирования, а с математики, которая лежит в основе всех разработок по этой теме.

Сделайте триггер BEFORE INSERT и задайте значение полям объекта NEW (как это и предполагается таким триггером by design)

SELECT p.* FROM peoples p --выбираем людей, для которых
WHERE NOT EXISTS ( --не существует
  SELECT 1 FROM cars c --машины
  WHERE c.peoples_id = p.id --принадлежаший этому человеку
  AND c.desc IN ('Mercedes', 'BMW') --и которая мерседес или бмв
)

Заменив NOT EXISTS на EXISTS можно получить обратный список - тех у кого есть мерс или бмв.
В случае поиска людей у которых НЕТ - полный аналог приведенного в ответе Rsa97 варианта с LEFT JOIN. Но в случае поиска людей у которых ЕСТЬ - вариант с LEFT JOIN может давать дублирующиеся строки, вариант с EXISTS всегда возвращает не более одной строки для каждого человека.

Для вашей ситуации придумали интерфейсы.

Вот смотрите, есть логика вывода (Котлин, надеюсь понятно что этот код делает):

interface Report {
  fun getAverageTime(): BigDecimal
}

fun printReport(report: Report) {
  println("Average time: ${report.getAverageTime()}") 
}

Мы получаем данные из отчета. И нас в этом месте мало волнует как именно эти данные рассчитаны и как обрабатывается 0. Это логика отчета. Мало того, у нас может быть несколько разных реализаций интерфейса Report, каждая из которых обрабатывает этот случай каким-то собственным образом, вплоть до того что кидает исключение и, в результате, возникает ошибка (обработка такого исключения за рамками этого примера).

Теперь у нас возникает необходимость добавить еще один параметр в отчет:

interface Report {
  fun getAverageTime(): BigDecimal
  fun getCountWithZeroTime(): Int
}

fun printReport(report: Report) {
  println("Average time: ${report.getAverageTime()}") 
  println("Participants have zero-time: ${report.getCountWithZeroTime()}")
}

И никакой преждевременной оптимизации, только структурированный код.

1. Сначала нужно обдумать что вы с этого будете иметь. Вы сможете переиспользовать эту логику? Вы сможете покрыть логику тестами? Иначе говоря, сформулировать цель такого рефакторинга.
   
2. Собственно цель и определит какую логику вы будете выделять. Если задача переиспользовать - значит есть какой-то второй сценарий использования. Смотрите на него, выделяете общие с первым элементы. Выделяете различающиеся элементы - думаете как правильно оформить общие и различные элементы в коде (наследование, композиция, декораторы и т.п. приемы). Собственно на этом этапе у вас появляется план рефакторинга. Если же цель - облегчить тестирование, то начинаете с обдумывания теста. И рассматриваете тест как второй сценарий использования.
   
3. Затем остается этот план рефакторинга претворить в жизнь.
   

SELECT SUM(confirmed_ones) AS confirmed_ones, SUM(rejected_ones) AS rejected_ones FROM (
  SELECT ... /*тут ваш запрос из вопроса */
)