Я бы даже сказал C и Асм обязательно с вашим "разработка электронных устройств, плат". Другое дело, что хотите Вы, хватит ли мотивации развиваться в этом направлении?
Все очень зависит от того, где узкое место. При больших объемах лучше обновлять не всю таблицу, а только то, что изменилось, например, по таблице логов. Опять же, все это имеет смысл при тяжелых операциях с данными, которые не выгодно выполнять при каждом запросе.
Жалко, конечно, что в MySQL материализованные представления не работают из коробки, поэтому придется все делать самому.
В смысле "всё работает но вылетает ошибка"? Что работает или не работает не могу сказать, кода не вижу, но во 2 и 3 строке "modules/db.php" не найдены файлы для инклюда "../modules/log_in.php" и "../modules/send_sms.php". При инклюде, текущей директорий инклюда будет точка входа, даже для инклюдов внутри заинклюженных файлов. Из-за того, что это может вносить некоторую неочевидность в работе, лучше подключать файлы по абсолютным путям, а не по относительным.
kiril9011, я бы с радостью, но реально не понимаю, что требуется. Запрос который выводит новые сообщения:
SELECT
*,
SUBSTRING(mes, 1, 30) AS `mes`,
DATE_FORMAT(date120, '%d.%m.%Y, %H:%i') as date_mes2
WHERE (user_id=:login OR user_idor=:login)
AND id>:last_id
выводит все строки у которых login совпадает с user_id или user_idor, и id>last_id, где last_id - максимальный id из уже отображенных сообщений, соответственно, если появился больший id - это новое сообщение.
Но я опять гадаю, что вам действительно нужно... Потому что "должен выводить новые сообщения, которые приходят" и "чтобы 1 строка с логином" у меня никак не вяжутся вместе. Может вам текст сообщений нужно конкатенировать, чтобы все новые сообщения в одну строку объеденить? Вот, опять гадаю...
У проекта должен быть один бизнес-процесс. Т.е. и верстальщик и все остальные должны быть включены в него. Не стоит выдумывать специфичные стадии, типа верстка. Задача верстальщика такая же как и другие, backlog - в работе - тестирование - приёмка - сделано, ну или что-то вроде этого. Если увлечься стадиями, то схема мутирует во что-то сложное и малопонятное. Так что стадии лучше плодить только при реальной необходимости. Но это лишь мое мнение, все делают по-разному
CLI - command line interface, первая ссылка google, даже ее не открывая гласит:
"@babel/cli. Babel comes with a built-in CLI which can be used to compile files from the command line."
Сперва нужно определиться с логикой, т.е. как это должно обрабатываться. Мы запрещаем добавлять дубли при попытке. Мы перезаписываем данные при загрзке новых данных с той же датой. А может стоит все же делать дубль и отправлять сообщение пользователю, чтобы он уже сам разбирался, какой из вариантов корректный, а какой следует удалить.
Запрос должен выводить все строки при совпадении login с user_id или user_idor. Из выборки нужно исключить идущие подряд строки, в которых user_id и user_idor совпадают со значениями предыдущих строк, и оставить только последнюю.
Так требуется? Совпадение определяем только по user_id и user_idor? mes и другие поля не важны?
Лучше такое дклать не в SQL, а в шаблоне представления. Но можете и в SQL не выводить повторяющиейся значения с помощью аналитики, по-моему подойдет LAG.
Так не фетчите все разом, извлекайте по одной строке с помощью fetch. А если сверху реальный код, и действительно нужна только последняя строка, то меняйте запрос.
gotohell, это понятно, храните на вашем сервере, но зачем организовывать доступ через http и хранить ссылки в СУБД? Мне кажется, что было бы правильнее поискать решение без програмирования и СУБД.
Почему php и mysql, кроме "так как раньше имел не большой опыт" ? Есть какие-то особые требования? Почему просто не подключить удаленную файловую систему?
В деловых играх поведение и есть решение кейса. Собеседования в IT, состоят из нескольких стадий и в части из них конечный результат важен. Конечно, никто не будет расстреливать за ошибку, человек имеет право на нее. Но когда "делал все правильно", а в итоге получил "некорректный результат", я бы стал проверять экзаменующего, его критерии "правильноделанья". Иначе, когда такие работники попадут на производство, то все отделы будут "все делать правильно", даже контроль качества подтвердит, что все работают "правильно", а в результате проект в нерабочем состоянии, ведь конечный результат не важен.
К примеру, в задаче на логику экзаменируемый получил неверный результат не потому, что все его логические выводы были верными, а потом произошло что-то магическое, нет, он допускал логические ошибки. В задаче на креативность просто нарушались первоначальные условия, если в команде при мозговом штурме, кто-то будет накидывать варианты, которые не вписываются условия, то это никак не поможет решению задачи. Поэтому поведение и конечный результат не такие уж далекостоящие вещи. Такими разными они становятся только в одном случае, когда кто-то не хочет, чтобы его работу было легко оценить.
good_beginer, тут вопрос не только что собирается, но и как, и как в СУБД настроены индексы. Если здесь уже действительно все ок, тогда готовьте витрины данных, собирайте данные, обрабатывайте и уже подготовленые используйте. Для этого исопльзуйте материализованые представления (materialized view). Но опять же без всей картины трудно чтото советовать