Slava Rozhnev

SELECT `name` 
FROM `example`
WHERE `status` = 'free'
ORDER BY `date`ASC
LIMIT 1;

Не?

Тоже писал бота для удаления сообщений с матом. Я создал список матерных корней и проверял наличие хотя бы одного корня в сообщении. Работало неплохо, но некоторые додумались писать мат с ошибками или на английском. Кстати пробелы не учитывались, то есть от слитного написания мата тоже помогало.

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

Словарь мата, который я использовал: https://github.com/lcomrade/mat-defender-discord-b...

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

что эффективнее: хранить в записи список id объектов, которые должны быть обработаны при обращении к этой записи, в виде строки (скрипт будет парсить строку и отрабатывать каждый id), либо сделать триггер и хранимую процедуру (MySQL), которая возьмёт эту работу на себя?

Ни то ни другое.

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

Но есть ещё косяк - в том, как хранятся данные. Упаковка набора данных в одну запись в виде CSV-списка - это тоже дурь в подавляющем большинстве случаев. Умные люди не зря придумали нормальные формы, которые позволяют обрабатывать данные максимально эффективным образом.

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

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

Ничто не мешает использовать оконный вариант агрегатных функций. Кроме слишком старой версии СУБД, не поддерживающей оконные функции, конечно.

SELECT MIN(`min_price`) OVER () as `min_price`, 
       MAX(`max_price`) OVER () as `max_price`, 
       `item_id` as `id`
FROM `product_table` 
WHERE `id` IN (SELECT  тут запрос)

Получишь все нужные id, и в каждой строке - нужные MIN и MAX.

======================

Akina, да, версия 5.7.21 и она, я так понимаю, не поддерживает оконные функции.

SELECT t2.min_price, 
       t2.max_price, 
       t1.item_id as id
FROM product_table t1
CROSS JOIN ( SELECT MIN(min_price) AS min_price, 
             MAX(max_price) AS max_price
             FROM product_table ) t2
WHERE t1.id IN (SELECT  тут запрос)

Это очень хороший вопрос, по многим причинам.

Во-первых, очень хорошо что он сам по себе поставлен. Обычно пользователи РНР не задумываются о таких "мелочах". Но на самом деле об этом должен думать каждый программист, делающий сайты
Во-вторых, здесь мы можем видеть довольно характерный баг Апача, который действительно, почему-то не выполняет директиву ErrorDocument для 500 ошибок, полученных от РНР. Ну и вообще, завязываться на Апач во времена доминирования Нжинкса как-то не очень дальновидно.
В-третьих, как правильно заметил Stalker_RED, сделать редирект при 500 статусе (или 500 статус при редиректе) невозможно - статус может быть только один. Да это и нет смысла делать - проще сразу на месте нужную страницу и прочитать.
В-четвертых, текущий подход, прямо скажем, не очень оптимальный:
- о роботах мы позаботились, о пользователе позаботились, но надо ещё не забыть и программиста. Которому как раз сообщение об ошибке-то нужно видеть во всех подробностях!
- просто отдать нужный НТТР код недостаточно - надо бы ещё и завершить работу скрипта.
- ловить все ошибки вручную через try-catch так себе удовольствие. И код раздувает,и поведение потом быстро не поменяешь. А если в какой-то момент захочется для отладки прикрутить whoops - это придётся по всем блокам бегать?

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

В самом простом варианте это будет что-то вроде такого:

set_exception_handler(function ($e)
{
    error_log($e);
    http_response_code(500);
    if (ini_get('display_errors')) {
        echo $e;
    } else {
        include 'pages/error_500.php';
    }
});

В теории, конечно, можно заменить error handler на глобальный try-catch который оборачивает точку входа, но это менее удобно. Тем более, что для обработки фатальных ошибок нужен свой отдельный обработчик, и в итоге код обработки ошибок начинает занимать довольно значительный объем и лучше конечно его инициализацию вынести отдельно.

https://github.com/laravel/laravel
https://github.com/laravel/lumen-framework

Никак не очищать.

На самом деле этот вопрос встречается довольно часто. Вот например популярный ответ на Stack Overflow, который подробно разбирает этот распространённое заблуждение: https://stackoverflow.com/a/3126175. И основная мысль там:

Понятие такой генерализованной "очистки данных" изначально бессмысленное и вредное.

Особенно такой вот индусской функцией, которая сама по себе - пример редкого идиотизма: сначала заменяем символы < и > на HTML сущности... а потом бодро пытаемся вырезать HTML теги. Которых к этому моменту в тексте не останется ни одного!
Или функция stripcslashes, которая здесь вообще ни к селу, ни к городу. Если я хочу написать сочетание \n, то с какой стати эта функция будет заменять его на перевод строки?
Всё что можно оставить из этого безумного набора - это trim(). Да и то не всегда. Как правильно заметил Rsa97, могут быть случаи, когда лидирующие пробелы имеют значение, например, при выводе форматированного кода. Кстати, этим как раз грешит Хабр. Если запостить код с отступами, то первый будет "съеден"!

Очистка

Любая "очистка" (хотя правильнее говорить про форматирование), имеет смысл только в определённом контексте.
И поэтому "очищать" надо только адресно, строго перед использованием в том или ином конкретном случае.

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

Больше того, "очистка" HTML поможет данным, выводимым в яваскрипт, как мёртвому припарки. То есть опять же - всегда надо понимать, в какой именно контекст мы выводим данные, и форматировать соответствующим образом. В частности любые данные передавать в яваскрипт только через json_encode()

И таких контекстов неисчислимое множество. Например, если мы используем переменную для передачи параметров в консольный скрипт, то надо обязательно обрабатывать её через escapeshellarg(). Если в регулярку - то preg_quote(). Имя файла для инклюда из переменной (хотя так делать вообще не стоит) надо хотя бы обрабатывать через basename(). И так далее.

Валидация

Если же наличие HTML тегов в поступающих данных противоречит техническому заданию, то надо заниматься не "очисткой", а валидацией: проверить регулярным выражением, есть ли в строке HTML теги. И если есть, то вернуть пользователю с сообщением об ошибке.

Защита БД

И кстати, по поводу "использую pdo".
На всякий случай уточню, что само по себе использование PDO не защищает ни от каких проблем
Важно помнить, что защита - это когда в базу данных отправляется строго константная строка запроса, полностью на 100% составленная из значений, прописанных в коде РНР, и в ней не используется ни одно значение, пришедшее в код извне. Причем PDO помогает здесь только наполовину, позволяя использовать в запросе подстановки вместо самих данных.
Но при этом для всех остальных частей запроса - например имен полей - у ПДО нет никакой защиты и её надо организовывать самостоятельно. Либо проверяя по белому списку, лабо, по крайней мере, прогоняя через регулярку.

Почитайте про оптимистические блокировки.

Типичная sql инъекция.
Строки нужно экранировать, прежде чем пихать в базу.
https://www.php.net/manual/ru/mysqli.real-escape-s...