Почему SQL заставляет меня повторять все неагрегированные поля из моего предложения SELECT в моем предложении GROUP BY?

Я склонен с вами согласиться - это один из многих случаев, когда SQL должен иметь несколько более разумные значения по умолчанию, чтобы нам всем не нужно было печатать. Например, представьте, если бы это было законно:

Select ClientName, InvoiceAmount, Sum(PaymentAmount) Group By *

где «*» означает «все неагрегированные поля». Если бы все знали, как это работает, не было бы путаницы. Вы можете добавить подписку в определенный список полей, если хотите сделать что-то сложное, но знак означает «все из них» (что в данном контексте означает все возможные).

Конечно, "*" здесь означает нечто иное, чем в предложении SELECT, поэтому, возможно, другой символ будет работать лучше:

Select ClientName, InvoiceAmount, Sum(PaymentAmount) Group By !

Есть еще несколько подобных областей, в которых SQL не так красноречив, как мог бы быть. Но на данный момент это, вероятно, слишком укоренилось, чтобы вносить такие большие изменения.

Поскольку это две разные вещи, вы можете группировать их по элементам, которых нет в предложении select.

РЕДАКТИРОВАТЬ:

Кроме того, безопасно ли делать это предположение?

У меня есть инструкция SQL

Select ClientName, InvAmt, Sum(PayAmt) as PayTot

«Правильно» ли сервер предполагать, что я хочу группировать по ClientName И InvoiceAmount? Я лично предпочитаю (и считаю, что это безопаснее) иметь этот код

Select ClientName, InvAmt, Sum(PayAmt) as PayTot
Group By ClientName

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

Select ClientName, Sum(InvAmt) as InvTot, Sum(PayAmt) as PayTot
Group By ClientName

Я надеюсь / ожидаю, что мы скоро увидим что-то более исчерпывающее; урок истории SQL по этой теме был бы полезен и информативен. Кто-нибудь? Кто-нибудь? Бьюллер?

Тем временем я могу наблюдать следующее:

SQL предшествует принципу DRY, по крайней мере, в той мере, в какой он был задокументирован в Прагматичный программист.

Не всем БД требуется полный список: например, Sybase с радостью выполнит такие запросы, как

SELECT a, b, COUNT(*)
FROM some_table
GROUP BY a

... что (по крайней мере, каждый раз, когда я случайно запускал такого монстра) часто приводит к таким огромным непреднамеренным наборам записей, что быстро возникают панические запросы, умоляющие администраторов баз данных отскочить от сервера. Результатом является своего рода частичный декартово произведение, но я думаю, что в основном это может быть неудача со стороны Sybase в правильной реализации стандарта SQL.

Возможно, нам понадобится сокращенная форма - назовите ее GroupSelect

GroupSelect Field1, Field2, sum(Field3) From SomeTable Where (X = "3")

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

Хорошая причина для этого в том, что вы чаще всего получали бы неверные результаты, если бы не указали все столбцы. Предположим, у вас есть три столбца: col1, col2 и col3.

Предположим, ваши данные выглядят так:

Col1  Col2 Col3
a      b    1
a      c    1
b      b    2
a      b    3

select col1, col2, sum(col3) from mytable group by col1, col2
даст следующие результаты:

Col1  Col2 Col3
a      b    4
a      c    1
b      b    2

Как бы он интерпретировал
select col1, col2, sum(col3) from mytable group by col1

Я предполагаю, что

Col1  Col2 Col3
a      b    5
a      c    5
b      b    2

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

Лично я рад, что group by требует полей.

Я согласен с GROUP BY ALL, GROUP BY * или чем-то подобным. Как упоминалось в исходном сообщении, в 99% (возможно, больше) случаев вы хотите сгруппировать по всем неагрегированным столбцам / выражениям.

Однако вот один пример, в котором вам понадобятся столбцы GROUP BY по причинам обратной совместимости.

SELECT 
  MIN(COUNT(*)) min_same_combination_cnt, 
  MAX(COUNT(*)) max_same_comb_cnt, 
  AVG(COUNT(*)) avg_same_comb_cnt, 
  SUM(COUNT(*)) total_records,
  COUNT(COUNT(*)) distinct_combinations_cnt
FROM <some table>
GROUP BY <list of columns>

Это работает в Oracle. Я использую его для оценки избирательности по столбцам. Группа по применяется к внутренней агрегатной функции. Затем наносится внешний заполнитель.

Было бы неплохо выдвинуть предложение по этому усовершенствованию стандарта SQL. Я просто не знаю, как это работает.

На самом деле, разве это не было бы в 100% случаев? Есть ли случай, когда у вас может быть (неагрегированный) столбец в выбранном элементе, которого нет в GROUP BY?

Но у меня нет ответа. Это определенно кажется неудобным моментом для языка.

Я разделяю мнение оператора о том, что повторение немного раздражает, особенно если неагрегированные поля содержат сложные инструкции, такие как if, функции и многое другое. Было бы неплохо, если бы в предложении group by было какое-то сокращение - хотя бы псевдоним столбца. Обращение к столбцам по номеру может быть другим вариантом, хотя, вероятно, имеет свои собственные проблемы.

Может возникнуть ситуация, когда вам нужно извлечь один идентификатор из всех сгруппированных строк и сумму их количества - например. В этом случае вы должны сгруппировать их по имени и оставить идентификаторы не сгруппированными. SQLite, похоже, работает именно так.

Так как группировка по приводит к одному кортежу для всей группы кортежей, поэтому другие атрибуты, не связанные с группировкой по, должны использоваться только в агрегатной функции. Если вы добавляете атрибут без группы по атрибуту в select, тогда sql не может решить, какое значение выбрать из этой группы.