Имя Фамилия

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

P.s. Гулится что получение списка файлов медленное, и имеет смысл сделать это заранее и сохранить его отдельным ассетом

Вроде в firebase нет ограничений на пуши (бесплатно и сколько угодно)
По-умолчанию есть квота в 600к в минуту, но если очень-очень нужно, то можно попросить больше.
https://firebase.google.com/docs/cloud-messaging/c...

Очень много пушей за очень малое время не получится отправить (нужно размазывать на несколько минут) и на такое получить квоту нельзя принципиально.
https://firebase.google.com/support/faq#fcm-quotas

Также рейт лимиты могут быть ограничены в пики, когда большая нагрузка на сервис, по тому нужно обрабатывать нормально ошибку 429 и равномерно размазывать свои уведомления в течение дня.
https://firebase.google.com/docs/cloud-messaging/c...

600к отправок в месяц, если они размазаны - это мало и врядли упрётся в какой-либо лимит.

Мне кажется это зависит от способа построения веб-приложения. Например как делаю я - не вижу одной точки входа заголовков и наоборот одну точка входа можно самому реализовать по другому.

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

В MySQL - GROUP BY, JSON_ARRAYAGG, IFNULL

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

сайт - это сервер. сервер -это backend.
Про какой "прямой поток" ты говоришь? Такого понятия нет в программировании

если есть сайт то очевидно есть какой-то сервер принимащий запросы?
и сайт и приложение это варианты отображающие состояние сервера
тогда "связь приложения с сайтом" обеспечивается через изменение состояния на сервере
а как именно изменять - зависит от апи этого конкретного сервера

Почитайте про Progressive Web Applications.

https://snipp.ru/php/phpquery

Считать разом все пары (`id`, `title`) в ассоциативный массив, обработать его, занося в новый массив id уникальных записей, затем порциями, например по сотне id, установить признак уникальности в базе, потом удалить все записи, где этот признак не установлен.
Но всё равно, в худшем случае будет 3 000 000*3 000 000/2 = 4 500 000 000 000 сравнений. Так что, в первую очередь надо ускорять функцию similar_text.

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

Паттерн внутри немного нечитаем по |, поэтому отделяем цифры любым доступным способом, в данном случае вот так. Обратите внимание что двойной пробел должен сработать раньше чем одинарный. Заметьте, что данный способ это просто удар в лоб, без использования регулярок.

$s = '|1||2||3||7|9|';
       $out =   trim (str_replace('|',' ', $s));
       $out =  str_replace(
           [1,2,3,7,9,'  ',' '],
           ['q','w','e','u','o',',',','],
           $out
       );
       echo $out;

preg_match_all('~\d+~', $s, $match);
echo implode(', ', array_map(fn($n) => '!qwertyuio'[$n], $match[0]));

Есть такая русская пословица, "дурная голова ногам покоя не даёт".
Вот она про это "изобретение".

- Что будет если пользователя взломали, и взломщик залогинен. Дальше пользователь бежит меняет пароль, но взломщик продолжит сидеть под пользователем, ибо файл.
- Что будет если пользователя вдруг забанят? А вы не сделали запрос к БД и не узнали этого.
- Вообще любая ситуация когда вам нужно получить актуальные данные о текущем авторизованном пользователе из базы, но вы этого не делаете, так как экономите на этом запросе. Например решили добавить роли пользователям на сайте, меняете role для юзера. Как без запроса к БД текущему пользователю это узнать, что у него поменялась роль и теперь доступны доп. функции?

Чтобы убрать этот долбозапрос

Поймите и примите простую истину - база данных создана для того чтобы РАБОТАТЬ, так пусть же работает и исполняет ваши долбозапросы. Не нужно тут ничего придумывать.

«Преждевременная оптимизация — корень всех зол». Дональд Кнут.

Проверяй функцией MAX() последний номер фото, не забыв указать в WHERE текущую дату