Ist SQL GROUP BY ein Konstruktionsfehler?

Question

Warum muss ich in SQL angeben, nach welchen Attributen gruppiert werden soll? Warum kann es nicht einfach alle Nicht-Aggregate verwenden?

Wenn ein Attribut nicht aggregiert ist und nicht in der GROUP BY Klausel dann nicht-deterministische Wahl wäre die einzige Option unter der Annahme, dass Tupel ungeordnet sind (mysql Art tut dies) und das ist eine riesige gotcha. Soweit ich weiß, erfordert Postgresql, dass alle Attribute, die nicht in der GROUP BY aggregiert werden, was sie als überflüssig erscheinen lässt.

• Übersehe ich etwas oder ist dies ein Fehler im Sprachdesign, der lockere Implementierungen fördert und Abfragen schwieriger zu schreiben macht?
• Wenn ich etwas übersehe, was ist eine Beispielabfrage, wo Gruppenattribute nicht abgeleitet werden können?

Answer 1

Sie müssen nicht nach genau der gleichen Sache gruppieren, die Sie auswählen, z. B. :

SQL:select priority,count(*) from rule_class
group by priority

PRIORITY   COUNT(*)
      70          1
      50          4
      30          1
      90          2
      10          4

SQL:select decode(priority,50,'Norm','Odd'),count(*) from rule_class
group by priority

DECO   COUNT(*)
Odd           1
Norm          4
Odd           1
Odd           2
Odd           4

SQL:select decode(priority,50,'Norm','Odd'),count(*) from rule_class
group by decode(priority,50,'Norm','Odd')

DECO   COUNT(*)
Norm          4
Odd           8

Answer 2

Es gibt einen weiteren Grund für Warum muss ich in SQL angeben, nach welchen Attributen gruppiert werden soll?

Lets sat haben wir zwei einfache Tabellen: friend y car , wo wir Informationen über unsere Freunde und ihre Autos speichern.

Und nehmen wir an, wir wollen die Daten aller unserer Freunde (aus der Tabelle friend ) und für jeden unserer Freunde, wie viele Autos sie jetzt besitzen, verkauft haben, verunfallt sind und die Gesamtzahl. Oh, und wir wollen die Älteren zuerst, die Jüngeren zuletzt.

Wir würden so etwas tun wie:

SELECT f.id
     , f.firstname
     , f.lastname
     , f.birthdate
     , COUNT(NOT c.sold AND NOT c.crashed) AS owned
     , COUNT(c.sold) AS sold
     , COUNT(c.crashed) AS crashed
     , COUNT(c.friendid) AS totalcars
FROM friend f
LEFT JOIN car c     <--to catch (shame!) those friends who have never had a car 
  ON f.id = c.friendid
GROUP BY f.id
       , f.firstname
       , f.lastname
       , f.birthdate
ORDER BY f.birthdate DESC

Aber brauchen wir wirklich all diese Felder in der GROUP BY ? Ist nicht jeder Freund auf einzigartige Weise durch seine id ? Mit anderen Worten, sind nicht die firstname, lastname and birthdate funktionell abhängig von der f.id ? Warum nicht einfach tun (wie wir in MySQL können):

SELECT f.id
     , f.firstname
     , f.lastname
     , f.birthdate
     , COUNT(NOT c.sold AND NOT c.crashed) AS owned
     , COUNT(c.sold) AS sold
     , COUNT(c.crashed) AS crashed
     , COUNT(c.friendid) AS totalcars
FROM friend f
LEFT JOIN car c     <--to catch (shame!) those friends who have never had a car 
  ON f.id = c.friendid
GROUP BY f.id
ORDER BY f.birthdate 

Und was wäre, wenn wir 20 Felder in der SELECT (plus ORDER BY ) Teile? Ist die zweite Abfrage nicht kürzer, klarer und wahrscheinlich schneller (in den RDBMS, die sie akzeptieren)?

Ich sage ja. Sagen also die SQL 1999 und 2003 Spezifikationen, wenn dieser Artikel korrekt ist: Entlarvung von Mythen über Gruppen

Answer 3

Ich würde sagen, wenn Sie eine große Anzahl von Elementen in der Gruppe von Klausel haben, dann vielleicht die Kerninfo sollte in eine tabellarische Unterabfrage, die Sie innere Join in gezogen werden.

Dies ist zwar mit einem Leistungseinbruch verbunden, sorgt aber für einen saubereren Code.

select  id, count(a), b, c, d
from    table
group by
        id, b, c, d

wird

select  id, myCount, b, c, d
from    table t
        inner join (
            select id, count(*) as myCount
            from table
            group by id
        ) as myCountTable on myCountTable.id = t.id

Dennoch bin ich daran interessiert, Gegenargumente zu hören, die dafür sprechen, dies zu tun, anstatt eine große Gruppe nach einer Klausel zu bilden.

Answer 4

Ich stimme zu, dass die Gruppe von Liste sollte nicht implizit das gleiche wie dann nicht aggregierte Spalten auswählen. In Sas gibt es Daten Aggregation Operationen, die mehr prägnant sind.

Außerdem: Es ist schwer, ein Beispiel zu finden, bei dem es nützlich wäre, eine längere Liste von Spalten in der Gruppenliste als in der Auswahlliste zu haben. Das Beste, was mir einfällt, ist ...

create table people
(  Nam char(10)
  ,Adr char(10)
)

insert into people values ('Peter', 'Tibet')
insert into people values ('Peter', 'OZ')
insert into people values ('Peter', 'OZ')

insert into people values ('Joe', 'NY')
insert into people values ('Joe', 'Texas')
insert into people values ('Joe', 'France')

-- Give me people where there is a duplicate address record

select * from people where nam in 
(
select nam              
from People        
group by nam, adr        -- group list different from select list
having count(*) > 1
)

Answer 5

Wenn es Ihnen nur darum geht, Skripte einfacher zu schreiben. Hier ist ein Tipp:

In MS SQL MGMS schreiben Sie eine Abfrage in Textform, etwa wie select * from my_table Danach wählen Sie den Text mit der rechten Maustaste aus und klicken Sie auf "Abfrage im Editor entwerfen ". Sql Studio öffnet einen neuen Editor mit allen Feldern, danach wieder Rechtsklick und "Add Gruop BY" wählen Sql MGM Studio wird den Code für Sie hinzufügen.

Ich finde diese Methode äußerst nützlich für Einfügeanweisungen. Wenn ich ein Skript zum Einfügen vieler Felder in eine Tabelle schreiben muss, mache ich einfach select * from table_where_want_to_insert und ändere danach den Typ der select-Anweisung in insert,