Сформировать правильный SQL запрос или поменять структуру таблиц?

Вы бы бы указали точно свою СУБД, включая точную версию, что ли. Потому как задача решается по щелчку пальцев оконной функцией в CTE - но поддерживает ли всё это СУБД?

Привожу таблицу с тестовыми данными:

И чё нам с этой "весёлой картинкой" делать? Выложи всё то же, но в виде кода CREATE TABLE + INSERT INTO.

если у контакта три категории с total_points 2, 0 и 8 соответственно, то категория этого контакта - 3 (с total_points 8).

А если 5,1,5? первая? третья? обе? что-то ещё?

Почему sql запрос возвращает NULL?

Николай,

непонятно для чего эта конструкция была придумана.

Скорее всего, программист не учёл, что значение может начинаться с числа.

Почему sql запрос возвращает NULL?

https://dbfiddle.uk/?rdbms=mysql_8.0&fiddle=d3a8b3...

Любые `text`, которые при CAST к числу, дают не ноль, в исходном запросе дадут "неверный" результат.

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

Почему sql запрос возвращает NULL?

в данном запросе должно было вернуться не Шерсть, а 100% полиэстер

Тогда не вижу проблемы.

После подстановки результата вместо подзапроса имеем

SELECT IF( !('100% полиэстер'), '100% полиэстер', 'NULL' )

Выражение условия приводится к числовому типу. Поскольку существует числовой префикс, он и получается. То есть делаем очередную подстановку и получаем

SELECT IF( ! 100, '100% полиэстер', 'NULL' )

100 в булевом контексте интерпретируется как TRUE. NOT 100 соответственно интерпретируется как FALSE. Делаем очередную подстановку и получаем

SELECT IF( FALSE, '100% полиэстер', 'NULL' )

Теперь понятно, почему возвращается 'NULL'?

Можно ли в хранимых процедурах создать временную функцию?

А можно ли создать временную функцию в хранимой процедуре?

А зачем? как-то больно на XY похоже...

Почему sql запрос возвращает NULL?

Null не может никак интерпретироваться.

Между терминами "интерпретироваться как" и "приводиться к" - дистанция огромного размера.

а теперь давайте усложним, представим что вложенный запрос возвращает шерсть.
select if('шерсть', 1, 2);

Условие содержит выражение 'шерсть'. Это выражение, согласно логике работы IF(), приводится к типу BOOLEAN, который на самом деле алиас TINYINT(1). То есть к числовому типу. Согласно правилам приведения, которые использует MySQL, при приведении строки к числу берётся числовой префикс строки, а при его отсутствии (строка начинается с нецифрового символа) результатом приведения будет ноль. Ноль интерпретируется как FALSE (или, если строго - то FALSE является алиасом целочисленного значения ноль). И выбирается альтернативный вариант.

Что "весело"? Всё логично и однозначно.

Почему sql запрос возвращает NULL?

Николай, Удалите из oc_product_attribute_test все записи, кроме 5-7 штук, проблемную тоже оставьте. Что-то типа DELETE FROM oc_product_attribute_test WHERE product_id NOT BETWEEN 19440 AND 19450; Проверьте, что проблема по-прежнему воспроизводится. Сделайте дамп и выложите - попробуем воспроизвести проблему и понять её источник.

А, ещё одно. Так, сбоку. А нафига нужен индекс KEY `1`? Он по идее вообще не должен использоваться ни в одном запросе, кроме тех, для которых он покрывающий.

Почему sql запрос возвращает NULL?

(null) - это NULL. Надеюсь, это вопросов не вызывает?

!(null), как я сказал выше, "!(NULL) - нормальное выражение булева типа, имеющее значение NULL".

Так что да - и то, и другое значение есть NULL. Который интерпретируется как FALSE (это я тоже говорил выше). Что в соответствии с логикой работы функции IF() (также описанной выше) приводит к выбору альтернативного значения. В обоих запросах.

И что не так-то? что не работает?

Почему sql запрос возвращает NULL?

Мне уже не нравится то, что данные в UTF8 (чарсет для отдельных полей не указан, значит, применяется дефолтный чарсет таблицы), тогда как и сервер, и соединение работают в UTF8MB4. Очень теоретически это может вызывать проблемы. А сверху ещё наслаиваются проблемы несовпадения COLLATION для данных и для литералов. MySQL в принципе считает эти чарсеты совместимыми, а collation вообще приводит неявно и хрен поймёшь по каким правилам...

Правда, всё это к именно описанной проблеме приводить не должно.

Так, следующий вопрос. Проблема - воспроизводима? т.е. если pa.product_id = 19442 косячит - то косячит абсолютно всегда? А если выгрузить десяток записей из таблицы, включая и запись для этого продукта, и положить в отдельную таблицу указанной структуры - всё равно проблема воспроизводится? А если этот же запрос выполнять не через PHP, а из клиента командной строки - проблема так же остаётся и воспроизводима?

PS. Charset / collation можно было бы дать текстом, как сделано для CREATE TABLE. А все три вывода - завернуть тегом кода, а не цитаты, для сохранения форматирования вывода.

Почему sql запрос возвращает NULL?

Дмитрий,

сразу лишаются смысла ибо при отсутствии записи будут давать один и тот же вариант.

Да, при отсутствии записи оба дадут 'NULL' (обращаю внимание - это не NULL, а 4-символьный строковый литерал с таким значением).

Насчёт смысла ничего не скажу - это к автору вопросы.

ибо кастинг null к boolean работать не будет

Да работает он, работает!

Правда, в MySQL ещё следует обычно учитывать неявное приведение типов (в нём вообще такого базового типа данных как BOOLEAN - нет), но не в данном случае. К слову, с точки зрения MySQL NULL при любых проверках действует как FALSE. Что обычно приводит к непониманию работы CHECK constraint, который, в отличие от IF(), проверяет, наоборот, на FALSE - но тут достаточно просто запомнить.

Почему sql запрос возвращает NULL?

Можно в MySQL запустить

Можно и не запускать. Ибо в полном соответствии с написанным выше оба запроса вернут двойку.

Почему sql запрос возвращает NULL?

Что-то у тебя всё плавает... запрос, который по твоему заверению возвращал "Шерсть", тут вернул "100% полиэстер", второй запрос вернул значение с маленькой буквы, хотя в вопросе написано с большой...

К самим значениям в хексах претензий нет - честная кириллица.

Структура таблицы oc_product_attribute

Это не структура, а, я извиняюсь, чушь собачья. Структура - это полный и не тронутый редактированием результат выполнения SHOW CREATE TABLE tablename;

Теперь проверяем второе подозрение. Выкладывайте структуру таблицы, а также результат выполнения SHOW VARIABLES LIKE 'char%'; и SHOW VARIABLES LIKE 'coll%';

Почему sql запрос возвращает NULL?

Предположу что стоит это понимать как то что NULL это специфическое значение, и для SQL и попытка привести к булеан через !(NULL) не работает;

Бред.

Напомню, что булево значение может иметь три разных варианта - TRUE, FALSE и UNKNOWN. Вот последнее в терминах SQL и есть NULL. Так что !(NULL) - нормальное выражение булева типа, имеющее значение NULL.

Логика работы IF() тупая и дубовая. Получили TRUE - выполняем первую альтернативу, иначе вторую, и неважно, FALSE это или NULL.

Почему sql запрос возвращает NULL?

Возвращает корректное значение - Шерсть

Что вернёт SELECT HEX(pa.text) FROM ... ?

Как исправить ошибку синтаксиса при COPY?

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

Код ожидает, что строки с данными будут передаваться через stdin. И завершение строк с данными строкой "\." говорит о том же - эти символы явно должны интерпретироваться как команда клиента, не требующая подтверждения нажатием Enter. А вот клиент уже ожидает следующего запроса - при выполнении COPY он обнаружил, что из stdin ему брать нечего, и успокоился на копировании нуля записей.

Почти убеждён, что между отдельными значениями полей там не пробелы, а табуляции.

PPS. Код можно было бы и под спойлер спрятать...

PHP не создаёт запись MySQL, ошибки не выводит, что делать?

Тимур Мамедов, ну сейчас ладно. А вообще на каждый пук индексов не насоздаёшься. Лучше всё-таки настроить нормально диагностику.

Почему не работает запрос к базе?

Собери текст запроса в отдельной переменной, а не в $mysql->query, покажи, что получилось.
Проверь, выполняется ли полученный запрос через CLI.
Включи обработку ошибок mysqli.

PHP не создаёт запись MySQL, ошибки не выводит, что делать?

No index used in query/prepared statement ...

Это не от MySQL прилетело, нет у него такого текста сообщения об ошибке...

PHP не создаёт запись MySQL, ошибки не выводит, что делать?

$create_table = mysqli_query($connect, "INSERT INTO `users`(`id`, `username`, `email`, `password`, `plan`, `banned`, `avatar`, `subscribers`, `status`, `used_plan`) VALUES (NULL, '$username', '$email', '$password', 3, 'no', '$rand1', 0, 'surfer', 3)");

Жадность, жадность.

Собери текст запроса в отдельной переменной, другой строкой выполняй. А в серединке - выведи куда-нибудь, сам посмотри да нам покажи. А ну как он косячный?

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

даже ошибку при выполнении не выводит!
error.log пустой

А включи на чутка General Log и посмотри, что пых шлёт на сервер. Может, твой запрос-то до муськи даже не добирается...

Как обойти проблему "LOAD DATA LOCAL INFILE file request rejected due to restrictions on access"?

Andrew_Novikov,

Вот, что я нашел: 'MySQL пытается прочитать файлы параметров в указанном выше порядке.

Во-первых, тут имеется в виду именно сервер MySQL, а не клиент mysql.exe. То, что получит клиент, берётся из секции [client] конфигурационного файла.
Во-вторых, список и порядок загрузки файлов конфигурации зависит от ОС. Подробнее тут: Using Option Files.
В третьих, файл конфигурации может быть указан в командной строке. Такой файл обрабатывается последним (или, если задано соотв. опцией - единственным).
В четвёртых, отдельные параметры могут указываться и в командной строке - тогда они имеют приоритет перед любыми файлами конфигурации. Но при наличии одноимённого параметра для сервера и для клиента то, что передано в опциях командной строки, однозначно воспринимается как серверная настройка.

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