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

Вадим Мурашкин,

Если количество "баллов" категорий совпадает, то должна выводиться только та, которую запросили (извне прилетает ID категории category_id).

Так тут ещё и параметр затесался? тогда вообще каша и никакой ясности...

В общем, глянь для затравочки: https://dbfiddle.uk/?rdbms=mariadb_10.4&fiddle=77a...
Для каждого юзера получена "максимальная" категория, и помечено, совпадает она с запрошенной или нет.

Сформировать правильный 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 и посмотри, что пых шлёт на сервер. Может, твой запрос-то до муськи даже не добирается...