Ты правда думаешь, что защитный файл и токен - они для красоты? Нет, они как раз для идентификации и аутентификации. Это как минимум. А ещё есть логи маршрутизирующего оборудования...
Короче, при правильно построенной системе (а судя по описанию, её не дураки строили) - вообще без шансов. Ну разве только что цель мероприятия - огрести себе проблем на нижние 90...
chemdev, если через запятую, то CASE, завёрнутые в CONCAT_WS. А если отдельными записями, то проще всего распивот с помощью UNION. Или сразу получить что требуется, как показывает YepBro
Чтобы разбить сеть на 8 подсетей, достаточно убедиться, что исходная сеть - /29 или шире. Впрочем, просто "шире" - термин некорректный, корректнее сказать "мЕньшее число" или "включает не менее 8 адресов".
Впрочем, если задача учебная, то ответ ROUNDUP(LOG2(8)) = 3 бита. Не менее чем на...
вывожу из бд значения в цикле, некоторые значения в полях имеют вид «привет|пока|что-то ещё» в итоге имеем 3 значения, но так не во всех полях, а в некоторых
Ну сразу два вывода.
Первый - БД организована неправильно. Тот, кто её делал, предпочёл не изучить нормальные формы, а высосать структуру из пальца. Получилось ... ну то, что получилось.
Второй - получение тоже организовано неправильно. Сервер БД, при правильно написанном запросе, легко и непринуждённо приведёт все данные к одному знаменателю. И сделает это гораздо быстрее и эффективнее, чем написанный одним программистом код, даже если этот программист гениален.
Итого. Если ещё пока есть возможность - лучше срочно переделать структуру хранения, даже если из-за этого придётся переписать запросы в половине приложения - всё равно экономия будет солидная, особенно на стадии эксплуатации и поддержки.
Что же до решения озвученной задачи без оглядки на её [censored] - можно выполнить последовательный парсинг в рекурсивном CTE, можно использовать синтетическую опорную таблицу чисел для парсинга... можно даже заменами преобразовать в JSON и обработать JSON_TABLE... но ни один из этих способов не будет эффективен.
продолжить вывод значений, которые не нужно разбивать через explode
Для унификации кода - explode-ить всё. Просто то, что не требует разделения, даст на выходе массив из 1 элемента.
Дайте ТОЧНОЕ определение того, какая дата является ближайшей.
А заодно, чтобы уж два раза не бегать - и К ЧЕМУ она должна быть ближайшей. По тексту я вижу литерал '2024-04-05 19:00:00' - то есть точка будет задаваться извне?
Для именно указанного запроса? ну навскидку где-то от 10 тысяч юзеров уже можно будет увидеть хоть какую разницу... и то при условии что сама таблица в принципе не влезает в кэш.
Для простого приложения - выясняйте сначала, от имени какой учётной записи оно выполняется.
Для службы - не делайте таких вещей... опять же некоторые службы имеют в параметрах что-то вроде "флага обязательности", и OS в принципе не даст остановить такую службу, потому что считает, что без неё работа самой OS невозможна.
PS. А можно полюбопытствовать - за каким хреном вы статический и непараметризованный запрос запускаете в цикле?