SELECTS выбирает только один элемент

Question

SELECTS выбирает только один элемент

0

У меня проблемы с этим выбором. Я хочу определить "pegada ecológica" каждого продукта с типом "lar". С этим выбором я смог получить первый продукт с типом "lar", но я хочу каждый продукт. Я не знаю, как это произошло.

SELECT DISTINCT P.codigo as "Código Produto", 
       SUM(Compra.quantidade)*SUM(Composto.percentagem)*SUM(E.pegadaEcologica) as "Pégada Ecológica"
FROM Produto P, Elemento E, composto Composto, compra Compra
WHERE P.tipo = 'lar' AND P.codigo = Composto.produto 
       AND Composto.elemento = E.codigo AND P.marca = Composto.prodMarca

Мои таблицы:

Create table  Elemento  (
  codigo    char(3),
  nome  varchar(25) not null,
  pegadaEcologica   int(2) not null,
  saude int(2) not null,
  constraint pk_Elemento     primary key (codigo)
);

Create table  Produto  (
  codigo    int(6),
  marca int(7),
  nome  varchar(50) not null,
  tipo  char(10),
  comercioJusto char(1),
  constraint Produto_tipo_RI004 check (tipo in ('alimentac','lar','jardim','automov','viagem','electrodom')),
  constraint Produto_comercioJusto_RI005     check (comercioJusto in ('A','B','C','D')),
  constraint fk_Produto_marca    foreign key (marca) references Marca(numero) on delete cascade,
  constraint pk_Produto  primary key (codigo,marca)
);


Create table  compra  (
  produto   int(6),
  prodMarca int(7),
  consumidor    int(9),
  quantidade    decimal(10,3)   not null,
  constraint compra_quantidade_RI006    check (quantidade>0),
  constraint fk_compra_produto   foreign key (produto,prodMarca) references Produto(codigo,marca) on delete cascade,
  constraint fk_compra_consumidor    foreign key (consumidor) references Consumidor(numero) on delete cascade,
  constraint pk_compra   primary key (produto,prodMarca,consumidor)
);


Create table  composto  (
  produto   int(6),
  prodMarca int(7),
  elemento  char(3),
  percentagem   decimal(4,1)    not null,
  constraint composto_percentagem_RI007 check (percentagem>0 and percentagem<=100),
  constraint fk_composto_produto     foreign key (produto,prodMarca) references Produto(codigo,marca) on delete cascade,
  constraint fk_composto_elemento    foreign key (elemento) references Elemento(codigo) on delete cascade,
  constraint pk_composto     primary key (produto,prodMarca,elemento)
);

ПРИМЕЧАНИЕ. Если вам нужны ВСТАВКИ, я их, дайте мне знать, и я тоже отправлю их.

Mariana Leites 11 дек. 2017, в 18:39

Источник

Теги:

mysql

sql

select

1 ответ

Ещё вопросы

JNevill · Accepted Answer · 2017-12-11T17-41-00.000Z

Вы агрегируете некоторые данные, используя функцию агрегации, такую как sum(), avg(), max(), group_concat() или аналогичные. В твоем случае:

SUM(Compra.quantidade)*SUM(Composto.percentagem)*SUM(E.pegadaEcologica)

Вы также выбираете поле, на котором вы группируете агрегированные данные.

P.codigo as "Código Produto",

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

SELECT P.codigo as "Código Produto", 
       SUM(Compra.quantidade)*SUM(Composto.percentagem)*SUM(E.pegadaEcologica) as "Pégada Ecológica"
FROM Produto P, Elemento E, composto Composto, compra Compra
WHERE P.tipo = 'lar' AND P.codigo = Composto.produto 
       AND Composto.elemento = E.codigo AND P.marca = Composto.prodMarca
GROUP BY P.codigo

Вы должны, как я это сделал, удалить ключевое слово DISTINCT. Distinct похож на GROUP BY, но правильно использовать его, когда вы не используете какие-либо агрегированные функции.

Наконец, было внесено изменение в настройку MySQL по умолчанию в 5.7 и новее, чтобы привести его в соответствие с большинством других продуктов RDBMS. Вы должны в новых версиях включать ваши неагрегированные поля в предложение GROUP BY, иначе парсер отклонит ваш запрос. Таким образом, он рекомендовал, чтобы вы всегда включали все ваши неагрегированные поля в свою группу GROUP BY. Это помогает будущему доказательству вашего SQL и делает его более переносимым (поскольку тот же самый оператор не сработает, если вы портируете это на Postgres или Oracle или SQL Server или почти любую другую базу данных).