Melkij

Markdown - формат текстовый. Значит как текст и сохранять.

Где вы потеряли переводы строк - mysql здесь ни при чём. Ему что сказали записать, то он и запишет, и это же потом прочитает. Может сами удаляете переводы строк перед записью, может - после. Может банально выводите в формат, невосприимчивый к переводам строк, например в HTML.

Детали, почему не удалось повесить внешний ключ можно найти в "логичном и очевидном" месте: в выводе команды SHOW ENGINE INNODB STATUS, есть кусочек текста LATEST FOREIGN KEY ERROR.

Частые ошибки - в одной таблице поле int, в другой unsigned int. Это разные, несовместимые типы, ага.

Размер одной индексной записи ограничен.
Для используемой у вас версии mysql, размера страницы памяти - максимальная длина индексной записи 767 байт. Т.е. 255 символов utf8, 191 символ utf8mb4 и соответствующая арифметика для составных ключей. Уменьшите поле или используйте индексный префикс чтобы длина индексной записи влезала в 767 байт.

Никак.
Глупый mysql не умеет рекурсивные запросы.

на выбор:
- меняете структуру хранения. nested sets или материализованный путь, например
- вытягиваете всё на приложение и строите там
- делаете МНОГО запросов
- пишете хранимку, которая будет делать много запросов
- если вложенность известна - то через n джойнов можно.

Текст как текст. У вас проблема, если код надо выводить как исполняемый, да ещё в контексте своего домена или вовсе исполнять на сервере.
А СУБД всё равно, что там за текст. Хоть вообще бинарник в blob писать. Правило одно - никогда не конкатенировать данные в управляющий запрос.

Сколько бесполезных манипуляций.

public static function getProductsList()
{
    $query = "select p.id, ...";
    return Db::getConnection()->query($query);
}

И mysqli и PDO для объекта результата давным давно предоставляют traversable. А плоский массив при необходимости многократно обходить результат получается элементарным fetchAll() без этой простыни.

<?php foreach ($productsList as $product): ?>
     <tr>
         <td><?=$product['id']; ?></td>
     </tr>
<?php endforeach; ?>

Если бы вы действительно делали var_dump, то уже давно бы заметили, что алиас таблицы ни PDO ни mysqli в результат не предоставляют. Только имена самих полей или алиасы этих полей.

Ну, это если считать, что PDO::ATTR_DEFAULT_FETCH_MODE у вас установлен в PDO::FETCH_ASSOC или хотя бы в дурацкий дефолтный PDO::FETCH_BOTH.

В любом случае у вас выключено отображение ошибок. Переключите error_reporting в нормальный девелоперский E_ALL.

Проблема в вашем коде. Наконец-то mysql начал об этом говорить. Нельзя писать в таблицу, не указывая явным образом значения для всех полей, не имеющих default значения.

Вероятно, вы смигрировались на mysql 5.7. Там как раз sql_mode дефолтный наконец-то изменили. А может просто более адекватно sql_mode выставлен админом.
dev.mysql.com/doc/refman/5.7/en/sql-mode.html
На сколько помню, за поведение ошибочного insert'а без указания non-default полей отвечают STRICT_ALL_TABLES, STRICT_TRANS_TABLES.

1. внешние ключи должны быть там и те, чтобы гарантировать ссылочную целостность. Должна быть ссылка сочетанием именно двух параметров - значит должна быть ссылка сочетанием пары параметров. Лучше или хуже сюда не применимо. Два разных fk и один составной имеют различное поведение.
2. для какой именно СУБД? Postgresql следуя стандарту SQL обязывает ссылаться только на уникальное поле. Mysql отступает и в этом вопросе от стандарта и позволяет проверять неуникальное индексированное поле.
3. см. coding standart конкретного проекта. Обычно никто не обижается против именования: имя таблицы _ имена полей _fk
4. можно упереться в предел размера индексируемого поля. У postgresql это 1/3 размера странички памяти = 2730 байт по дефолту, у mysql - зависит от кучи факторов.

Включите в sql_mode режим ONLY_FULL_GROUP_BY и тогда, наконец-то, этот странный mysql перестанет разрешать делать странные вещи с группировкой, отчего получаются не менее странные результаты, зависящие от фазы луны .

www.sql.ru/forum/687908/faq-vyborka-pervoy-posledn...

mysql> explain select test6.i from test6, test9 where test6.i=test9.i;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra                                              |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+
|  1 | SIMPLE      | test6 | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    2 |   100.00 | NULL                                               |
|  1 | SIMPLE      | test9 | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |    25.00 | Using where; Using join buffer (Block Nested Loop) |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+
2 rows in set, 1 warning (0,00 sec)

mysql> show warnings;
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message                                                                                                                                 |
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------+
| Note  | 1003 | /* select#1 */ select `test`.`test6`.`i` AS `i` from `test`.`test6` join `test`.`test9` where (`test`.`test9`.`i` = `test`.`test6`.`i`) |
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0,00 sec)

mysql> explain select test6.i from test6 join test9 on test6.i=test9.i;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra                                              |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+
|  1 | SIMPLE      | test6 | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    2 |   100.00 | NULL                                               |
|  1 | SIMPLE      | test9 | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |    25.00 | Using where; Using join buffer (Block Nested Loop) |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+
2 rows in set, 1 warning (0,00 sec)

mysql> show warnings;
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message                                                                                                                                 |
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------+
| Note  | 1003 | /* select#1 */ select `test`.`test6`.`i` AS `i` from `test`.`test6` join `test`.`test9` where (`test`.`test9`.`i` = `test`.`test6`.`i`) |
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0,00 sec)

Как можно заметить, оба стиля переписаны в одно и то же представление.

Имеет смысл использовать join on по соображениям читаемости человеком, т.к. такой join сразу говорит, по каким полям связаны таблицы, а where органично остаётся для фильтрации.
Плюс, в случае как у вас со связью по паре одноимённых полей можно написать

SELECT maker, price FROM Product JOIN PC USING(model)

Что эквивалентно PC.model = Product.model, но короче и позволяет в дальнейшем ссылаться просто на model - парсер уже знает, что значение поля будет идентично и не будет теряться в догадках, хотели вы получить model из PC или из Product

Переключите PDO::ATTR_ERRMODE в единственный адекватный режим PDO::ERRMODE_EXCEPTION.
Нормальный поток исполнения - вас не заботят ошибки в SQL, раз метод вернул управление, значит он был выполнен успешно.
Случилась какая-то ошибка - словили исключение. Если для какой-то конкретной ошибки вам нужна своя реакция - то тогда уже выясняете код именно этой ошибки, смотрите в getCode и реагируете на конкретный код ошибки.