Shavadrius

Шансы от этого не зависят.
Учиться в любом случае придётся самостоятельно.

Сразу готовый JSON из базы данных:

WITH countries_links AS (
    SELECT JSON_OBJECT('name', `name`, 'iso2', `iso2`, 'links', COUNT(`link_id`)) d
    FROM `links`
    JOIN `countries` ON `countries`.`iso2` = `links`.`country`
    GROUP BY `name`, `iso2`
    HAVING COUNT(`link_id`) > 0
) SELECT JSON_ARRAYAGG(d) FROM countries_links

Пример: https://sqlize.online/sql/mysql80/087bf8ba4f587b13...

Потому что владельцы магазинов хотят что бы покупали в их магазинах, а не в сторонних приложениях

ведь его браузер новые стили не прочитает

Бразуер кеширует конкретный файл. Соответственно, для сброса кэша просто меняют путь к файлу.
Простой вариант: добавить get-параметр, в котором будет содержаться время последнего изменения. Но этот вариант требует чтения с диска на сервере, чтобы узнать mtime (не велика беда) и работает не со всеми reverse proxy (некоторые криво настроенные могут игнорировать get-параметры).
Поэтому уже лет десять существуют системы сборки фронтенда, которые прямо в имя файла подставляю хэш от его содержимого. Сейчас это есть для абсолютно любой системы - gulp, webpack, что угодно.
Называется это Cache Busting, вот вам первая попавшаяся статья: https://www.keycdn.com/support/what-is-cache-busting
А ещё, кэш - это не только "не запрашивай файл 365 дней", там много различных функций: https://jakearchibald.com/2016/caching-best-practices/

при их изменении на стороне клиента

Такая формулировка подразумевает, что это клиент что-то меняет. Я уж обрадовался: "о, какой интересный вопрос, есть над чем подумать!"...

0 возвращает не &.

& - жадный оператор. И левый, и правый операнд будут вычислены.
&& - ленивый. Если значение левого операнда false, то второй операнд даже не будет вычисляться.

Получается, что в первом случае выражение вычисляется полностью:
true & false & false -> false
Выражение firstNumber++ > 0 имеет значение false, тк это пост-инкремент.
В результате значение firstNumber=1 тк инкремент был вызван.

Во втором случае инкремент не будет вызван, тк значение выражение будет очевидно в самом начале:
(true && false)&& ... -> false
Тк инкремент не вызван, secondNumber=0

Тут подходит любая реляционная SQL БД потому что нет противопоказаний. Реляционку мы выбираем
уже более 30 лет как default вариант и почти не ошибаемся.

Когда задача имеет признаки ярко выраженной high-load системы - мы делаем ей частичную денормализацию
и раскладываем ее в NoSQL Key-Value решение. Но это не про улучшение а это про неизбежность. У нас нет выхода просто.
Иначе мы клиенту не сможем быстро отдать какой-то резуальтат.

Когда задача имеет ярко выраженную документную природу (нет спецификации на values) - мы берем MongoDb/CouchDb.

Когда задача хранит граф и ищет в графе и вообще требует графовых алгоритмов - то мы берем Neo4j или ей подобные.

Когда задача хранит данные измерений (телеметрия) - то предпочтительно взять InfluxDb или ей подобные. Здесь-же мы предполагаем что у нас - не будет joins а будет только измерения в диапазоне времени.

Но в данном ТЗ и на картинке обычная SQL БД (MySQL/Postgres) вполне себе нормально справляется.

Бизнес-логика - это то ради чего создается приложение.
На примере калькулятора, это все, что связано с расчетами: сложение, вычитание, деление и т.д.
Бизнес логику всегда можно описать в формате "юзер-стори".

В приложении есть еще другие компоненты не связанные напрямую с бизнес-логикой: это все интеграции, рендеринг фронта (если такой присутствует), все, что связанно с жизненым циклом приложения и т.д. Можно это назвать, наверное, "логикой приложения", но я лично, что-то такого определения не встречал.

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

Владимир, вы бы еще архитектуру хелловорлда взялись "понимать".
Если хотите понять в двух словах, то можно применить такой принцип: бизнес-логика - это то, ЧТО должно выполнять приложение. А логика приложения - то, КАК оно это выполняет. Гругря, "по заказу формируются документы в формате XLSX и PDF" - это бизнес-логика. А вот запрос к БД за данными заказа, разбор шаблона документа, использование библиотек для генерации файлов нужного формата - это логика приложения. Отталкиваясь от такого примитивного понимания, можно разглядеть уровни в коде: где программист размахивает человекопонятными блоками и выполняет техзадание, а где - копается в байтах, соединениях и потоках вывода. Если мы одно от другого отделяем, то оказывается, что низкий уровень для большинства задач один и тот же и его можно опять-таки собрать в библиотеки и практически без изменений использовать там, где понадобилась другая бизнес-логика, но использован тот же технологический стек.

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

Логика приложения - всё что связано с взаимодействием с пользователем. Кнопки, формы, итд.

Если следовать этому термину, то все кнопки это бизнес логика, т.к. человек на них нажимает, а результат это логика приложения, верно?

Нет. Кнопки - это логика пользовательского интерфейса. Бизнес-логика - то, что за этими кнопками на самом деле стоит.

Прямо в первой же строке ссылка, по которой находится ответ на ваш вопрос.

Но часто всё-таки добавляют искусственный первичный ключ "Номер".

Основная идея первичных ключей - неизменяемость и уникальность. В качестве ключа может использоваться, например, инвентарный номер или isbn, даже если содержит буквы/символы, т.к. он физически уникален и не изменяем. С другой стороны есть очень много вещей, которые могут меняться: фио, номера телефонов, логины. И если изменить это данные, то придется изменить их и во всех таблицах, которые ссылаются на эти данные. И чтобы избежать таких ситуаций и используют искусственные ключи.