Mylistryx

Никак.
в кодировке windows-1251 примерно 200 символов
в UTF-8 - миллионы.
Запихнуть миллион символов в 200 физически невозможно.
Поэтому либо перестать использовать у себя пещерную кодировку, либо городить ручную замену для всех неподдерживаемых символов, тупо строковой заменой.

Я думаю здесь подмена понятий. Автор пишет "кэширует ли БД запросы", а имеет в виду "может ли в принципе эта страшная и непонятная громадина которая называется базой данных в принципе хоть когда-нибудь рабтотать быстро?"
Все, разумеется, кидаются отвечать на первый вопрос.
А на самом деле надо отвечать на второй. Да, почти всегда БД работает гораздо быстрее чем ты можешь вообразить и ничего кэшировать не нужно. Если вдруг стало работать медленно... впрочем, об этом ниже.

Нужно ли делать кеширование запросов
Вот в такой формулировке, взятой с потолка, "а не закэшировать ли мне запросы к базе данных*" - Нет, не нужно.

и как?
Очень просто.
Три простых шага:
1. Понять, устраивает ли тебя производительность приложения. Если устраивает, то все оставить как есть.
2. Если не устраивает, освоить профайлинг. Если это слово не упоминается в вопросе про производительность или кэширование, то вопрос можно сразу удалять. потому что он заведомо взят с потолка и не имеет смысла. По сути, профайлинг - это замер скорости выполнения отдельных участков кода для поиска узких мест - т.е. таких участков кода, которые тормозят всю программу. Это можно делать и вручную, и с помощью различных готовых инструментов. Только по результатам профайлинга, который показал конкретную причину тормозов, то самое узкое место (его еще называют bottleneck, "бутылочное горлышко"), можно приступать к оптимизации. Не кэшированию!
3. Если профайлинг показал, что проблема в конкретном запросе к БД, приступаем к его оптимизации. Чаще всего достаточно добавить индекс или донастроить сервер.
4. Только если все другие способы не помогли - занимаемся кэшированием. Но перед этим сначала решаем Вторую Важнейшую Проблему Информационных Технологий - инвалидации кэша. Поскольку закэшировать - это ерунда, каждый дурак сможет. Самая главная проблема не в том, как данные положить в кэш, а как и когда их оттуда удалять.

1. В DDD подразумевается предметная разработка. Соотвественно CRUD тут не совсем правильно делать. Тут нужно работать с UseCase: создай товар, удали товар, оплатить товар, архивировать товар. Это уже больше чем CRUD.
2. Во фреймворке делайте своё ядро, которое принимает DTO. Запихиваете данные в DTO далее передаёте в сервис, обрабатываете данные и пихаете через Repository в базу. В принципе все просто. Можете посмотреть курс Елисеева Дмитрия по работе с интернет магазином. Если говорить о примерах, то вот, правда на симфони.

Так же есть пример из самого магазина

Если делать в один поток:
(Сначала, работаем БЕЗ базы)
1. Берём CSV и расставляем (формируя два новых файла рядом!) через консольный скрипт/программу в нём ID-шники согласно "таблице-связке" (которая тоже в файле хранится, её изначально надо будет сделать однократно): [ID в CSV] -> [ID в нашей базе]. Это может быть как артикул, так и название (или любой другой уникальный параметр для одной уникальной записи, включая хэширование).
Получаем CSV2-update (связанные записи) и CSV2-new (записи, которых нет в нашей БД).

(сортировка - по желанию, но она не нужна)

(Начинаем работать с базой)
2. Обновляем сначала те, что есть: CSV2-update
3. Затем, добавляем в БД новые позиции: CSV2-new.

4. После добавления - обновляем файл "таблицы-связок".

Итог:
1. Мы все "тяжёлые" операции делаем ВНЕ базы.
2. Мы ничего не ищем по базе, а сразу берём нужную запись по ID ("ключу").

Захотите сделать сразу всё и мультипоточно на PHP: pthreads в помощь!

Расширение - это дополнительные модули в PHP, они реализуют конкретно в вашем случае работу с CURL и JSON.
Узнать подключенные модули
https://www.php.net/manual/ru/function.extension-l...
Список всех модулей
https://www.php.net/manual/ru/extensions.alphabeti...

Если на вашем сервере они установленны, то не факт что они будут установленны и на другом сервере. Поэтому PHPStorm рекоммендует добавить их в правила композера, чтоб в случае разворачивания на другом сервере, композер сообщил вам что расширения отсутсвуют

Если бесит инспектор, то можете отключить это уведомление.

Статические ссылки на текущий класс, такие как self:: или __CLASS__, вычисляются используя класс, к которому эта функция принадлежит, как и в том месте, где она была определена
...
Позднее статическое связывание пытается устранить это ограничение, предоставляя ключевое слово, которое ссылается на класс, вызванный непосредственно в ходе выполнения.

Позднее статическое связывание

Решение:

public static function getMessage(): string
{
  return 'message - ' . static::getString();
}

MYISAM не поддерживают FOREIGN KEY. Используйте InnoDB для этого. По поводу поля COMMENT - такой поддержки нет.

Можно, как это сделать описано в официальной документации. Но вот только зачем? работать с помощью Composer гораздо удобнее и надежнее

Возможно как то так,

[
    ['user_id', 'invite_id'],
    'unique',
    'targetAttribute' => ['user_id', 'invite_id'],
    'filter' => [
        'or',
        ['user_id' => $this->invite_id],
        ['invite_id' => $this->user_id],
    ]
],

<?php

use yii\db\Migration;

class m160322_045630_add_catalog_data extends Migration {

    public function safeUp()
    {
        Yii::$app->db->createCommand()->batchInsert('country', ['name'], [
            ['Австралия'],
            ['Австрия'],
            ['Азербайджан'],
            ['Албания'],
        ])->execute();
 
    }

    public function safeDown()
    {
        Yii::$app->db->createCommand()->delete('country', ['in', 'name', ['Австралия', 'Австрия', 'Азербайджан', 'Албания']]
        )->execute();

    }

В модели getShortText() реализуйте как хотите и используйте $model->shortText