Почему результаты max() не верные (mysql)?

FanatPHP,

судя по longtext, это все равно какой-нибудь учебный проект

При чём тут это? EAV, самый тривиальный - какой ещё тип данных может быть?

Почему результаты max() не верные (mysql)?

, longtext... можно как ту в mysql указать что бы он менял тип данных в колонке для того что бы max() верно отработал?

Тип данных един для всех записей. А числовые данные для правильного отбора и сортировки именно как чисел следует хранить нормализованным до установленной длины ведущими нулями (и, сабо самой, то же делать с критериями отбора). LPAD() в помощь...

Вывести данные из таблицы A которые не совпадают с данными в таблице B?

почему?

Соблаговолите показать, где именно применяется установленное исходным заданием условие

То есть:

A.id != B.id_task AND B.id_user != $id_user

Найти количество чисел меньше заданного?

Отсортировать A[].
Отсортировать Q[], сохраняя номер исходной позиции.
Пройти по паре массивов двумя указателями, получить нужные данные.
Отсортировать Q[] по номеру исходной позиции.
Отдать результат.

Как составить запрос в PostgreSql?

если запрашивает owner или admin

Как это определяется?

если запрашивает owner или admin то добавляем атрибуты 'approved', 'published', 'publishedAt', 'createdAt',

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

если запрос делает guest, то ставим ставим условие where published=true.

WHERE @current_user != 'guest' OR products.published=true

Вывести данные из таблицы A которые не совпадают с данными в таблице B?

Решение не соответствует исходному заданию.

Как заставить GROUP BY и подзапрос в Mysql выдавать нужный вариант таблицы?

В изначальном варианте Ваше условие проверяло, что c.value_sale содержит значение, отличное от NULL и нуля.

В показанном же на скриншоте варианте - логика есть. Но Вы не учитываете, что значение MAX() появляется после выполнения GROUP BY, тогда как WHERE выполняется до группировки. Возможное решение - перенос условия из WHERE в HAVING.

Но последний запрос отличается от того, что показано в вопросе, причём в худшую сторону. Например, Вы пишете c.date = CURRENT_DATE() - 1. Если Вы думаете, что это минус день - огорчу. В таком варианте контекст выполнения - числовой, и если CURRENT_DATE() - первое число месяца, запрос выдаст ошибку. Следует использовать c.date = CURRENT_DATE() - INTERVAL 1 DAY.

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

Как заставить GROUP BY и подзапрос в Mysql выдавать нужный вариант таблицы?

feniksdv, нет, я спросил, что делает именно WHERE. По сортировке и лимитированию вопросов нет.

Как заставить GROUP BY и подзапрос в Mysql выдавать нужный вариант таблицы?

Не надо картинок, лечить по фотографиям - это шарлатанство. Создайте fiddle? например, на https://dbfiddle.uk/?rdbms=mysql_8.0

PS. Что, по-Вашему, делает/проверяет WHERE c.value_sale в подзапросе?

Почему не видно устройство?

Проверьте настройки роутера. Возможно, включено изолирование портов - т.е. в Инет можно, а к соседу ни-ни...

Зачем удалять вопросы, если можно их скорректировать?

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

Зачем удалять вопросы, если можно их скорректировать?

Насчёт "отправьте его в какое-нибудь временное хранилище" - боюсь, что такого просто нет. Создавать его точно никто не станет. Разве что создать некий тег, темы которого видны только модераторам и авторам (кстати, тоже не факт, что это возможно).

А вот с тем, что удаление - это неправильно, согласен на 100%.

Более того, я бы вообще запретил удаления тем (особенно тем, имеющих ответы). Не, вот какого хрена? С момента публикации тема перестаёт быть собственностью автора - так откуда у него право единолично принимать решение об удалении? тем более, когда в теме имеется труд других участников, которые имеют прав на эту тему ну по крайней мере не меньше. Да, у модератора в этом отношении прав поболе, но опять же, "вот нам больше делать нечего" - так себе обоснование.

Как правильно составить SQL-запрос?

Нужно вывести самого популярного автора за год.

Гм... а что это такое - самый популярный?

Автор, книги которого брали наибольшее количество раз?
Автор, процент читанных книг которого от общего количества его книг - максимален?
Автор, для которого средняя продолжительность нахождения у читателя его книги наибольшая?
Автор, у которого наибольшее количество отказов в выдаче, потому что все книги на руках?
Автор, у которого наибольшее количество книг не возвращено (по любым обстоятельствам)?

Или, может, что-то ещё?

Ну и до кучи - как учитывать автора, если у него есть книги как личные, так и в соавторстве?

Добавление даты и время в таблицу (в момент запроса)?

Djasar, а какая разница-то?

Как правильно использовать Boolean индекс?

grabbee,

Я нашел инфу о том, что это обычное поведение потому как в индексе всего два значения 1 и 0 - оптимизитор считает его бесполезным

Полезность индекса оценивается на основании статистики, а не из абстрактного количества имеющихся значений.

Как вставить SELECT в UPDATE?

СУБД, судя по тексту сообщения об ошибке, MySQL?

Оказалось нельзя использовать SELECT внутри UPDATE.

Неправда, можно. Просто делать это надо правильно.

Как удалить дубли товаров woocommerce, если одинаковы цена и название?

Ну тогда обычное

DELETE t1
FROM table t1
WHERE EXISTS ( SELECT NULL
               FROM table t2
               WHERE t1.name = t2.name
                 AND t1.price = t2.price
                 AND t1.id > t2.id )

Или то же в форме JOIN.

Как удалить дубли товаров woocommerce, если одинаковы цена и название?

И не забыть при этом все ссылки на удаляемый дубль переписать на оставляемый оригинал...

Как лучше организовать хранение и релевантный поиск по нескольким тегам?

FanatPHP,

Чтобы новый тег добавить, делать alter table, серьёзно?

Нафига на каждый-то? SET маппится на BIGINT, так что только на каждый 64-й. А если программно маппить его на блоб - то вообще никаких проблем с расширением. И по сути это ну ничем не отличатся от дополнительных таблиц - просто вместо двух таблиц (метаданных и связующей) появляется одна таблица метаданных. С той лишь разницей, что для SET tcnm специально прикормленные инструменты, а классический M:N - это постоянные группировки или динамический SQL.

Как лучше организовать хранение и релевантный поиск по нескольким тегам?

И чем неизвестный тег, формализованный в SET, отличается от столь же неизвестного тега, формализованного в таблице-справочнике?