FanatPHP

https://www.php.net/manual/en/function.ctype-digit.php

preg_match_all('/(\w+)=(\w+)/', $str, $matches);
$data = array_combine($matches[1], $matches[2]);

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

Вам не нужно сохранять pdf в БД. Это не имеет смысла. Достаточно хранить данные из которых он генерируется и потом делать это на лету. В крайнем случае, если ожидается 100500 скачиваний можете сохранить его в storage. Наверняка ваша библиотека это позволяет.

БД на файлах называется SQLite и не надо изобретать ничего другого
расширение для работы с sqlite встроено в РНР начиная ещё с версии 5.3, кажется
почитать про inodes

Нет. Фреймворк тут играет последнюю роль. 10000 человек в день это немного, меньше одного запроса в секунду в среднем, надо смотреть на нагрузку в пике. В любом случае надо анализировать слабые места - запросы к базе, количество веб серверов для обработки запросов, возможность кеширования и асинхронной обработки...
UPD. У Вас в вопросе написано и пиковая нагрузка 10000, и 10000 за день, что в итоге?))
Все равно результат нужно сводить к предварительному профилированию и только потом к тюнингу серверов или рефакторингу

у вас какая-то дичь в запросах: АБС, множественные подстроки и все такое.
мускуль отлично работает с датами, в частности, оператор BETWEEN.

1) Часто при написании условий легко спутать = и ==. В данном случае стороннему разработчику придется понять, что это НЕ опечатка. Даже стандарт сделали, чтобы избежать таких ошибок, используется в Symfony, называется Yoda Conditions. https://en.wikipedia.org/wiki/Yoda_conditions#Erro...
2) Читать другому разработчику такую конструкцию не удобно, т.к. обычно ожидаешь в условии увидеть какое-то сравнение. А сейчас требуется разобраться, что мы одновременно присваиваем и делаем проверку.

Исходя из пунктов выше, я бы не рекомендовал использовать такие конструкции.
Альтернатива, сделать присвоение перед условием явно:

public static function get($id)
{
    $user_bank = self::findOneBy('`user_id` = ?', [$id]);
    if (!$user_bank) {
        $user_bank = new self();
        $user_bank->user_id = $id;
        $user_bank->deposit = 0;
        $user_bank->deposit_sum = 0;
        $user_bank->percent = 10;
        $user_bank->exchange_sum = 0;
        $user_bank->save();
    } 
    return $user_bank;
}

PS: Но в итоге ответ зависит от того, что для Вас значит "приемлемо":

* значит, что понятно другому разработчику? - В общем случае не приемлемо. В случае договоренности (стандартам) в команде/на проекте, приемлемо.
* значит что код, просто работает? - приемлемо.

PPS: Похожий вопрос на англ. языке https://stackoverflow.com/questions/2576571/assign...