Ипатьев

Тем не менее сейчас я столкнулся с тем, что на собеседованиях начинают спрашивать что серьезного доводилось делать на чистом php - без фреймворков и мои ответы на их вопросы касательно парсеров, скиптов для обмена данными остаются неубедительными. Даже дальше кадровиков иногда дело не уходит.

Вы неубедительны. Парировать надо. Ну найдите разраба, который в угоду своему ЭГО, будет писать проект на чистом php, который в будущем сможет поддерживать только он.

Еще спрашивюат какие патерные проектирования используешь, придерживаешься ли принципов Solid?

Вы недостаточно сильны в этом вопросе, SOLID опять же не про фреймворки.

А сейчас я не только ради прохождения собеседований, но и ради повышения скилла хотел бы углублённо погрузиться в написание кода без фреймворков. Но как к этому подойти? Не писать .же бложег или интернет-магазин на чистом php?

Зачем вам это? Изучать как работает PHP и смежные вещи - одно. Писать пет проекты чтобы закинуть их в ящик - другое.

Может начать с изучения PSR

Нужно, сразу после того, как вы начнете понимать php.

от него начать писат простой psr фреймворк как это делал Дмитрий Елисеев?

А что это вам даст?

Или просто взять симфони и начать писать на ней чтоб понять суть вещей глубже и потом козырять своими скиллами на собеседованиях, что, мол, ,я тут на Симфони пишу, а вы мне тут вопросы для школьников задаёте?

А при чем тут симфони и вопросы школьников?

Короче расскажите мне про роудмеп погружения в php. Теорию я и так знаю - книги по php читал.

Сначала начните с того, как искать в гугле. Полезный навык, помогает.
https://github.com/thecodeholic/php-developer-roadmap

Вы можете использовать JSON_ARRAYAGG и JSON_OBJECT :

SELECT cat.id, cat.name, JSON_ARRAYAGG(
  JSON_OBJECT('pro_name',pro.name,'pro_pice',pro.price)
) prod
FROM products as pro
JOIN categories as cat on pro.cat_id = cat.id
GROUP BY cat.id, cat.name
ORDER BY cat.id;

MySQL JSON aggregate

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

postgres:
    ports:
      - 5432:5432
    networks:
      - app-network

Но в вашем случае вам нужно из одного обратиться к другому. Судя по всему вы хотите сделать коннект к БД из вашего приложения, но у вас указан localhost. Нужно прописать postgres вместо него

То есть исходники есть как в JPG/PNG так и в формате CDR

"То есть" ничего не объясняет. Это наложение текста сделано в Кореле или просто какой-то чудак импортировал в него фотки?
Во втором случае это совершенно бессмысленная информация.
В первом - с проприетарным кореловским форматом, насколько мне известно, возился только sk1. Но вроде бы достаточно успешно возился, вплоть до того, что на его базе сделаны такие, например, инструменты: https://convertio.co/ru/cdr-sk1/
Если в файлах таки есть текстовый слой и его можно будет сконвертировать во что-то открытое - останется работа с текстом и замена его в открытом формате.

P.S. Просто в SVG может не быть возможности пустить текст по кривой, и экспорт в него раздербанит тексты по буковке. А в EPS, например, таки есть.

Прочитал, что в mysql в движке innodb индексы делятся на два больших типа - первичный и вторичный

Понятия первичного и вторичного индексов никак не связаны с СУБД. И это не типы индексов по большому счёту. Просто первичный - однозначно идентифицирует запись (что определяется ограничениями на значение выражения и используемых в нём полей), тогда как вторичный - всего лишь может использоваться для однозначной идентификации, но лишь при условии, что он отвечает всем требованиям-ограничениям для первичного.

В InnoDB - всего лишь есть дополнение, что при наличии первичного индекса он является также и кластерным. Для других движков и других СУБД такой зависимости может и не быть.

кластеризованный, как написано хранится с данными

Не-а. Кластерный индекс - это когда записи в теле таблицы (т.е. сами данные таблицы) хранятся в порядке сортировки по выражению этого кластерного индекса.

Всегда ли не кластиризованные индексы хранятся в оперативной памяти или это как-то можно регулировать?

Индексы всегда хранятся на диске. В оперативной памяти индексы могут всего лишь кэшироваться. Для ускорения доступа.

Я слышал что индексы должны быть в пределах мегабайт, а не гигабайт.

Или не о том слышал, или не так понял. Индексы никому и ничего не должны по части своего размера, который определяется суммарным размером данных индексного выражения, количеством записей и коэффициентом заполнения.

Читал, что бывает так, что индекс в таблице индекса хранит сразу данные определенных столбцов, а не ссылки на эти строки в основной таблице.

Вероятно, речь про INCLUDE-предложение в структуре индекса, имеющееся, например, в SQL Server... т.е. значения полей хранятся в выражении индекса как дополнительные данные, и не используются при сортировке.

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

В файлах