Челендж на 2026

Мы знаем про ПОДГОТОВЛЕННЫЕ ЗАПРОСЫ и кто их подготовил знаем лично вчера видали, подготовка неплохая. Только не о них речь идет. Мы говорим о ЗАПЕЧЕННЫХ, ЗАХАРДКОДЖЕНЫХ ЗАПРОСАХ (как вам удобно прости господи) в контексте ФРЕЙМВОРКА. А в остальном вы правы, опыта и знаний в разработке алогичного безумия у нас нет. 

"SELECT * FROM users WHERE name = '$name'"

вместо имени не кинул, что-то типа?

DROP TABLE users;

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

table('users') ->where('name', $name) ->get();

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

public function get(string $key, array|bool|float|int|string|null $default = null): array|bool|float|int|string|null
    {
        [$configName, $parts] = $this->parseKey($key);
        $value = $this->props[$configName];
        if (empty($parts)) {
            return $value;
        }
        foreach ($parts as $part) {
            if (is_array($value) && isset($value[$part])) {
                $value = $value[$part];
            } else {
                return $default;
            }
        }

        return $value;
    }

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

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

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

Ну существующие билдеры вполне себе справляются. У меня на первом этапе нет необходимости реализовывать абсолютно все возможности всех SQL диалектов.  По времени. Вопрос спорный и смотря с чем сравнивать.  Это все же фреймворк тоесть инструмент которому нужна гибкость. По факту я подумывал (заметь подумывал, но  в итоге так и не отрефакторил) уйти от кверибилдера только на проекте где RPS бывает до 1500 . Мой прогноз твоя история с тем как именно ты работаешь с XML будет тормозить сильно больше чем кверибилдер.  И тут может показать реальный тест: в идеале с профайлером, можно придумать иной тест и даже сравнительный :)

Опять же при грамотном подходе кверибилдеры не гоняются на каждом хите. Ну да ладно. посмотрим ;)

Какая должна быть нагрузка по вашему мнению, чтоб ощутить бяку? На нагрузке 1500 rps (без учета статики) - проблем нет (при этом была необходимость в одну очень нагруженную таблицу: читать, обновлять, писать и при этом практически нельзя кешировать. Нащупали предел - убрали ее в отдельную БД и все пошло без проблем). Более того, при большой нагрузке и если сконцентрироваться на том, что мы рассматриваем случай, когда результаты не закешированы и идет запрос в базу. В общем случае в первую очередь затыкается база, особенно если запросы на обновление присутствуют. (а если MyIASM - так там вообще легко базу заткнуть).

Как считаете для многих сайтов нагрузка в 1500 rps является обычной?

PS Да конечно, 1500 это еще не хайлоад, но хайлоад вообще живет по своим законам.

Ну, если тебе хочется отчетов каждую пятницу: идешь по ссылке на гитхаб и смотришь там на ту ветку, что указана - не проблема ж для тебя столь требовательного? 

Разрешаю даже каждый день туда заглядывать ;)