invalid use of group function

На чтение 3 мин. Опубликовано

I am using MySQL. Here is my schema:

Suppliers(sid: integer, sname: string, address string)

Parts(pid: integer, pname: string, color: string)

Catalog(sid: integer, pid: integer, cost: real)

(primary keys are bolded)

I am trying to write a query to select all parts that are made by at least two suppliers:

First off, am I even going about this the right way?

Secondly, I get this error:

1111 — Invalid use of group function

What am I doing wrong?

Содержание
  1. 2 Answers 2
  2. 1 ответ 1
  3. Похожие
  4. Вот примеры запросов
  5. По отдельности все работает
  6. Решение
  7. UPD: Создадим процедуру и евент для этого события
  8. Комментарии

2 Answers 2

You need to use HAVING , not WHERE .

The difference is: the WHERE clause filters which rows MySQL selects. Then MySQL groups the rows together and aggregates the numbers for your COUNT function.

HAVING is like WHERE , only it happens after the COUNT value has been computed, so it’ll work as you expect. Rewrite your subquery as:

First, the error you’re getting is due to where you’re using the COUNT function — you can’t use an aggregate (or group) function in the WHERE clause.

Second, instead of using a subquery, simply join the table to itself:

Which I believe should return only rows where at least two rows exist with the same pid but there is are at least 2 sid s. To make sure you get back only one row per pid I’ve applied a grouping clause.

Ребята как мне реализовать этот вариант :

Как я понял count в месте агрегатными функциями невозможно.

Как мне сделать выборку тогда ?

1 ответ 1

Как уже написали в комментариях, у вас две проблемы:

  1. В JOIN не указано условие ON по какому полю(ям) таблицы должны быть соединены.
  2. Отсечение записей по агрегатным функциям должно быть в предложении HAVING после GROUP BY .

Ваш запрос должен выглядеть как-то так:

Похожие

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

дизайн сайта / логотип © 2019 Stack Exchange Inc; пользовательское содержимое попадает под действие лицензии cc by-sa 4.0 с указанием ссылки на источник. rev 2019.11.15.35459

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

Вот примеры запросов

Попробуем вложенный селект:

По отдельности все работает

Выводим «размер шрифта»:

Обновляем поле с размером шрифта:

Решение

Погуглив, и поломав голову с disc’ом, я пришел к следующему решению, представленное ниже.

Я решил выделить вычисление процента в переменную @percent, далее создал вьюху для таблицы «categories» и жойню таблицу с вьюхой:

Вот и все, приятного манокурения 🙂

UPD: Создадим процедуру и евент для этого события

Комментарии

Adw0rd, Насколько я понимаю что после выполнения данной процедуры, что после желаемого изначально UPDATE, у нас будет стопицот категорий, с одним и тем же значением size .
Внимание вопрос: «Зачем хранить одно и то же значение в 9342423 экземплярах? Как же нормализация?»

ИМХО: по крону раз в те-же сутки меняем значение «.categories_cloud <
font-size. » в CSS файле и не усложняем зря жизнь себе и БД 🙂

Ну а так да, вполне себе приятное решение.

Насколько я понимаю что после выполнения данной процедуры, что после желаемого изначально UPDATE, у нас будет стопицот категорий, с одним и тем же значением `size`

Нет, не будет, я же проверяю сначала, прежде чем публиковать. 😉

Зачем хранить одно и то же значение в 9342423 экземплярах? Как же нормализация?

вот что получается

Никаких «9342423 экземплярах» 😉

И вот такое облако получаем:

Нет, не будет, я же проверяю сначала, прежде чем публиковать. 😉

Хм. Просто запрос:

У меня лично выдает только одно значение — 1.2500(Как я понимаю для последнего столбца с id 19 (MySQL5). Или я что-то недопонимаю?

ИМХО все равно данные размера как таковые к категориям особого отношения не имеют, они грубо говоря связь облака тегов с категориями, да и юзаются они ведь только в нем, не так ли?

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

Ну и в ней собственно все их(значения) хранить.

да, именно этот запрос сделает всем строкам один результат, но этот запрос только для теста, посмотри внимательно процедуру, там этот кусок кода:

вынесен в отдельную переменную @percent и все работает наура, для всех строк

ИМХО все равно данные размера как таковые к категориям особого отношения не имеют, они грубо говоря связь облака тегов с категориями, да и юзаются они ведь только в нем, не так ли?

Не согласен, зачем мне делать доп. таблицу, если эти данные необходимы для генерации облака (титл, урл, размер)?

Я считаю это лишним.

Поэтому можно было бы сделать таблицу: Ну и в ней собственно все их(значения) хранить.

С тем же успехом можно было отделить «count» в другую таблицу.

count имеет отношение к категориям,
size имеет отношение исключительно к облакам и нефиг ему делать в основной таблице.

Впрочем на вкус и цвет товарищей нет. Проехали 🙂

Ну да я это понял, просто меня переклинило на первом запросе, стормозил признаю.

P.S.
Впринципе вполне логично, что они гененрят только одну строку ибо MAX, MIN это же агрегатные функции GROUP BY.
Можно было бы заменить аццким запросом:

Твой вариант лучше безусловно прозрачнее и быстрее, мне просто занятся нечем пока футурама скачивается.

`size` имеет отношение исключительно к облакам и нефиг ему делать в основной таблице.

Ну смотри, для генерации облака нам нужно помимо «размера» еще «имя жанра» и «ссылка, либо ид жанра», так?

Тогда логично чтобы они были в одной таблице, чтобы не делать лишнего жойна, так?

Тогда куда мне всунуть «размер»? Или ты мне предлагаешь одинаковые данные хранить в двух таблицах?

Оцените статью