FanatPHP

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

Поэтому переделываешь свою БД, добавляешь новые таблицы и колонки, раскодируешь свой развесистый джейсон и записываешь каждое значение в свою ячейку

Не нужен парсинг для того, что тебе просто дают в руки.

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

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

Правда, традиционно "файл с SQL запросами" обычно называется репозиторием , а "репозиторий" - сервисом или хелпером.

В общем, нормальная структура такая

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

то есть запросы

SELECT count(field) FROM table WHERE a<100;
SELECT count(field) FROM table WHERE a=1 AND field_1 = 'd'; 
SELECT count(field) FROM table WHERE a=1 AND field_1 = 'd'  and date between 2019 and 2020;

это ОДИН метод

Лучше документации никто не объяснит.
и примеры там тоже есть.

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

1 воркер дает 1 подключение к серверу?

нет

если кол-во воркеров 4, то 5й пользователь уже не сможет подключиться?

сможет

Я правильно понимаю что клиент постоянно держит соединение с сервером?

правильно

если он откроет 10 вкладок в браузере, то это будет 10 подключений?

будет
только непонятно при чем здесь php-fpm

Как работае вебсокет с сервером

веб-сокет не работает с сервером. вебсокет работает с клиентом

Ну то есть ты спрашиваешь, что лучше - один класс на 10000 строк или сто классов по 100 строк?
Тебе самому ответ не очевиден?

Очередная погоня за воображаемыми проблемами.

Тебе русским шрифтом пишут, сервер не раскрывает, существует ли учетная запись. Что в этом предложении не ясно?

За попытку отправить на несуществующий адрес никто в черные списки не добавляет.
Не говоря уже о том, что если следовать твоей логике, то ты все равно попадёшь, поскльку проверка адреса и заключается в попытке отправить письмо.

А "репутация" поддерживается совсем другими средствами, а не случайными телодвижениями на основе ночных фантазий

История простая.
Когда компьютеры были большими а оперативная память стоила как самолет, были изобретены реляционные СУБД, который хранили данные на диске, а индексы - в памяти. Работают быстро, масштабируются, оптимизируются, хранят данные в легко описываемой и структурированной форме.

Когда оперативная память подешевела, появились стильные модные молодежные базы данных типа nosql. Которые делятся на тупо живущие в оперативе, то есть по сути не являющиеся базами данных вообще, а скорее кэширующими демонами, как например пример редис, и "документо-ориентированные" БД, которые тоже живут исключительно если только целиком помещаются в оперативе, как например Монго. Из-за принципа "храним всё как бог на душу положит", каждая запись содержит не только сами данные, но и их структуру - имена полей, вложенность, и пр. То есть если в реляционной БД ты просто смотришь на заголовок таблицы, и понимаешь, в какое поле тебе класть вот эти данные, то в no-sql ты перебираешь ВСЕ записи в поисках нужного поля. И все равно одни и те же данные в итоге хранятся в десятках разных полей. Ну и добавляет удобства ещё то, что поскольку все имена полей хранятся вместе с записями, то сообразительные разработчики для экономии памяти сокращают имена до одной-двух букв. Что конечно сильно облегчает работу с базой

Ну и есть еще специализированные БД, например хранящие данные не в строках, как реляционные, не в пампасах, как nosql, а в колонках, для быстрой агрегации. Например Кликхаус.

Есть еще всякая мелочь, типа key-value storage, но у меня не поднимается рука называть их БД. Не называешь же ты массив в программе базой данных.

Чтобы сделать вывод конкретного исключения, надо его создать. Например

class SooperPooperException extends BaseException {}

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

try {
    // вызываем свой код который может кинуть исключение
} catch (SooperPooperException $e) {
   // рендерим ответ
}

Но при этом никаких корневых исключений не ловить, а только те, которые содержат текст для пользователя

Расписываю подробно:
Устанавливаешь Лару, пишешь код.

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

И нет, не надо мне доказывать, что все верно. Доказыавть надо своей базе данных. Если бы было всё верно, соединилось бы без проблем. Л - логика.

Пользователь бд идентифицируется тремя пунктами - имя, пароль и хост, с которого соединяется.
Вот и надо смотреть, есть ли пользователь user@localhost с таким паролем
И дальше надо смотреть какие права у этого пользователя на указанную при коннекте бд