ThunderCat

https://stackoverflow.com/questions/15001611/how-t...
Оно?

Что мешает залить, перевести, захватить звук и потом смонтировать? Налету десктопного ничего похожего пока нет.

1) Агрегационные функции по типу груп бай очень серьезно сказываются на времени запроса.
2)

если их там 500+будет парсинг займет много времени

Естественно, по уму надо таскать только свежие/обновленные, иначе точно наступит жпа. А со свежими естественно выборка уже будет совсем небольшой.

Хинт: Я бы не стал заморачиваться с жсоном или аггрегацией вообще в запросе, думаю парсинг массива на бэке имхо будет гораздо быстрее запроса, что в принципе не сложно проверить, если есть готовая база.

$_POST = json_encode($_POST); - смысл этой строки объясните?

есть же готовая панель, lte admin, там уже вроде есть компоненты для фронта...

https://adminlte.io/ например

что-то с ними делать по таймеру.

Да и хочется возникновения события вовремя, а не когда там сработает очередной поиск по cron.

Так по таймеру, или по експирации? Если у вас речь идет о каком-то событии типа "просрочено" или "напомнить", делайте просто выборку с учетом условия при запросе данных.

Если неймется именно прям менять состояние сущностей - тоже можно делать это
а) по запросу от клиента. То есть предположим вы выбираете какие-то сообщения для пользователя, которые 1) не протухли по времени, 2) не имеют статус "протух", и 3) принадлежат этому пользователю. Перед этим можно сделать апдейт с этими условиями, только выбрать старые без статуса "протух" и записать им статус. Подходит если делаются частые небольшие выборки, тогда большинство запросов будет копеечными по ресурсам, а некоторые вообще никогда статус не поменяют, что значит данные слишком холодные и на них спокойно можно забить болт. Минус - перед выборокой клиенту будет задержка на апдейт бд, скорее всего это комар чихнул нагрузки, но как факт...

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

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

https://dev.mysql.com/doc/refman/8.0/en/regexp.html

mb_str_replace()

У вас там 2 разных "ё" - пример

сообщение - это три значения: id, from_id (отправитель), to_id (получатель), msg (сообщение).

Точно три??? А то я плохо считаю на пальцах... А еще неплохо было бы дату сообщения как то хранить, и собсно по ней сортировать...

Мы получим дупликаты. Как поступить?

Дубликаты чего?

Как поступить?

Зависит от того что вам нужно, в приведенных запросах вы получаете всю выборку, так как лимит на количество записей у вас не обозначен. Последний запрос с ограничением в одну запись я думаю подойдет, но я бы все же рекомендовал добавить дату (чисто по логике- хотелось бы знать кто и что когда кому отправлял) и уже по дате делал ордер.

С 1 октября летсенкрипт сменила корневой сертификат, обновляйте у себя версию.

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

Я туплю и так задумано, или вы не оттуда тянете файлы?

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

Если у каждого пользователя он свой, то зачем вам его куда-то писать на фронте? Проверяйте это на сервере.

Я бы хотела передавать этот ключ когда пользователь заполняет форму авторизации, что бы прописать, что если логин: Петя, то передаем ключ 123, если логин Вася передают ключ 443.

Очень интересно как вы будете знать что это Петя, если пользователь еще не авторизирован?

конечно ключ буду передавать через скрытое поле.

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

Как абсолютно верно заметил Роман Юрьевич Ипатьев, проблема не в вызове аргументов, а в абсолютно нелогичном подходе к архитектуре, которая тут просто швах...

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

Файл RouteController.php обрабатывает URL

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

и делает вывод о типе контроллера (гость, авторизованный пользователь или администратор).

Как тип контроллера соотносится с ролью пользователя?

Создаёт объект этого контроллера и отправляет в него аргументами (str)имя контроллера и (str) полученный URL.

У вас же уже вызван контроллер, RouteController.php, либо он не контроллер, либо зачем тогда снова контроллер создавать? И зачем ему урл?

Эти аргументы попадают в родительский контроллер файла Controller.php и оттуда далее используются в условном ветвлении и передаются в соответствующие функции, где дальше из этих функций опять передаются в нужные функции.

Сложнааа, слоожжнаа (с) Карина. Очень запутанно и очень странно работает ваша творческая мысль.

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

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