nicht angemeldet
SQL Abfrage mit count und nur ausgeben wenn count größer 1
Rolf bIch habe eine Abfrage:
SELECT Maschinennummer, count(Kundennummer) AS Anzahl
FROM MaschinenOrte
GROUP BY Maschinennummer
Die gibt bspw. als Anzahl 1, 2 oder 3 usw... aus. Ich möchte aber nur die Datensätze angezeigt haben, die größer als 1 sind. Wie mache ich das?
Danke
-
Tach!
Ich möchte aber nur die Datensätze angezeigt haben, die größer als 1 sind. Wie mache ich das?
Mit einer HAVING-Klausel hinter dem GROUP BY.
dedlfix.
-
SELECT Maschinennummer, count(Kundennummer) AS Anzahl FROM MaschinenOrte GROUP BY MaschinennummerCOUNT(Kundennummer) zählt alle Sätze, wo die Kundennummer nicht null ist. Brauchst Du diesen Filter oder willst Du einfach nur wissen, wieviele Maschinenorte Du pro Maschinennummer hast? Im letzteren Fall reicht COUNT(*).
HAVING COUNT(*) > 1(oderHAVING COUNT(Kundennummer)>1) hinter GROUP BY Maschinennummer erfüllt im Übrigen deinen Wunsch. HAVING Anzahl > 1 wäre sprechender, geht meines Wissens aber nicht, weil rein formal in dem Moment, wo HAVING verarbeitet wird, die Spalten noch nicht projiziert sind.Rolf
-
Tach!
HAVING Anzahl > 1 wäre sprechender, geht meines Wissens aber nicht, weil rein formal in dem Moment, wo HAVING verarbeitet wird, die Spalten noch nicht projiziert sind.
Doch. Having arbeitet auf der Ergebnismenge, die die SELECT-Klausel erzeugt hat. In der Abarbeitung liegt SELECT zwischen GROUP BY und HAVING.
dedlfix.
-
Hallo dedlfix,
Doch. Having arbeitet auf der Ergebnismenge, die die SELECT-Klausel erzeugt hat. In der Abarbeitung liegt SELECT zwischen GROUP BY und HAVING.
Nein, da wirfst du Sachen durcheinander.
Ja,
HAVINGarbeitet auf dem Result Set. Jedoch nicht auf dem viaSELECTerzeugten, sondern auf dem Result-Set vor dem auswerten der Spaltenliste - die wird nämlich zuletzt ausgewertet. Standard-gerecht wird einSELECT-Statement nach diesem Schema ausgewertet:- Zuerst wird ein Produkt aller Tabellen in der
FROM-Klausel erstellt - Danach wird die
WHERE-Klausel ausgewertet, um Zeilen zu entfernen, die den Filter-Bedingungen nicht entsprechen - Danach werden die Gruppen wie im
GROUP BYdefiniert gebildet - Danach werden die Gruppen entfernt, die nicht den Filter-Bedingungen in der
HAVING-Klausel entsprechen - Danach werden die Ausdrücke in der
SELECT-Klausel ausgewertet - Danach werden doppelte Reihen entfernt, die auf die
DISTINCT-Klausel passen - Danach wird die Ergebnismenge durch ein eventuelles
UNIONzusammengeführt mit den anderen Subqueries - Zuletzt werden die Zeilen sortiert wie im
ORDER BYdefiniert
Natürlich gehen die DBMSe ggfls Abkürzungen, etwa beim auswerten der
WHERE-Klausel (die muss nicht erst auf dem vollständigen Produkt passieren), aber es zeigt klar warum welcher Ausdruck wo sichtbar oder nicht sichtbar ist.Ich habe keine Ahnung, ob der Zettelkasten anders handelt. In PostgreSQL ist das jedoch auch so umgesetzt. Ausdrücke aus der column list im
HAVINGreferenzieren ist nicht möglich.LG,
CK-
Tach!
Doch. Having arbeitet auf der Ergebnismenge, die die SELECT-Klausel erzeugt hat. In der Abarbeitung liegt SELECT zwischen GROUP BY und HAVING.
Nein, da wirfst du Sachen durcheinander.
Ja,
HAVINGarbeitet auf dem Result Set. Jedoch nicht auf dem viaSELECTerzeugten, sondern auf dem Result-Set vor dem auswerten der Spaltenliste - die wird nämlich zuletzt ausgewertet.MySQL arbeitet da anders, da kann man sich mit HAVING auf das SELECT-Resultset beziehen. (Dem "zuletzt ausgewertet" widersprichst du dir ja nachfolgend selbst, das muss ich nicht tun.) Der OP hatte kein DBMS angegeben, und so ging ich vom Quasi-Standard im Webumfeld aus.
dedlfix.
-
Hallo dedlfix,
MySQL arbeitet da anders, da kann man sich mit HAVING auf das SELECT-Resultset beziehen.
Das mag sein, ändert aber nichts daran wie es definiert ist. MySQL erlaubt es auch ungruppierte Spalten zu selektieren und so undefinierte Resultsets zu erzeugen, macht es halt alles nicht besser.
Der OP hatte kein DBMS angegeben, und so ging ich vom Quasi-Standard im Webumfeld aus.
MySQL als Quasi-Standard auszugeben ist mutig und vermutlich nicht wahr. Das globale Ranking kürt Oracle zum einsamen Spitzenreiter; betrachtet man nur MySQL und PostgreSQL, so gibt es etwa dreimal so viele MySQL-Instanzen. Da würde ich nicht von einem Quasi-Standard reden wollen.
LG,
CK-
Tach!
Der OP hatte kein DBMS angegeben, und so ging ich vom Quasi-Standard im Webumfeld aus.
MySQL als Quasi-Standard auszugeben ist mutig und vermutlich nicht wahr. Das globale Ranking kürt Oracle zum einsamen Spitzenreiter; betrachtet man nur MySQL und PostgreSQL, so gibt es etwa dreimal so viele MySQL-Instanzen. Da würde ich nicht von einem Quasi-Standard reden wollen.
Vielleicht muss ich "im Webumfeld" noch weiter einschränken auf "und das was der typische Frager hier verwendet". Wo gibts denn das globale Ranking für DBMS-Instanzen im Webumfeld?
dedlfix.
-
Hallo dedlfix,
Wo gibts denn das globale Ranking für DBMS-Instanzen im Webumfeld?
Ich sprach vom globalen Ranking, nicht vom globalen Ranking im Webumfeld.
LG,
CK-
Tach!
Wo gibts denn das globale Ranking für DBMS-Instanzen im Webumfeld?
Ich sprach vom globalen Ranking, nicht vom globalen Ranking im Webumfeld.
Ich sprach aber nur vom Webumfeld und du hast mir da widersprochen. Also passt dein Widerspruch gar nicht zu meiner Aussage. Wie war das mit der Empfehlung, genau zu lesen? (Und warum sehe ich da so viel Glas um mich herum?)
dedlfix.
-
Hallo dedlfix,
Ich sprach aber nur vom Webumfeld und du hast mir da widersprochen. Also passt dein Widerspruch gar nicht zu meiner Aussage.
Da wir in beiden Projekten die globalen Zahlen betrachten ist die Vergleichbarkeit weiterhin gegeben. Und da beide Datenbanken hauptsächlich im Web-Umfeld benutzt werden umso mehr.
LG,
CK
-
-
-
-
-
- Zuerst wird ein Produkt aller Tabellen in der
-
-
SELECT Maschinennummer, count(Kundennummer) AS Anzahl FROM MaschinenOrte GROUP BY MaschinennummerCOUNT(Kundennummer) zählt alle Sätze, wo die Kundennummer nicht null ist. Brauchst Du diesen Filter oder willst Du einfach nur wissen, wieviele Maschinenorte Du pro Maschinennummer hast? Im letzteren Fall reicht COUNT(*).
HAVING COUNT(*) > 1(oderHAVING COUNT(Kundennummer)>1) hinter GROUP BY Maschinennummer erfüllt im Übrigen deinen Wunsch. HAVING Anzahl > 1 wäre sprechender, geht meines Wissens aber nicht, weil rein formal in dem Moment, wo HAVING verarbeitet wird, die Spalten noch nicht projiziert sind.Rolf
Vielen Dank, mit Having funktioniert es (COUNT(Kundennummer)>1), leider nicht mit HAVING Anzahl > 1
-
Sag ich doch :)
Zur Reihenfolge: Microsoft sieht das anders, siehe Logical Processing Order. Da ist SELECT hinter HAVING. Allerdings scheint es MySQL tatsächlich anders zu halten, da steht ausdrücklich dass man Aliasnamen aus SELECT im HAVING verwenden darf.
Zwei Server, getrennt durch eine gemeinsame Sprache SQL...
Rolf
-
Hallo Rolf,
Zur Reihenfolge: Microsoft sieht das anders, siehe Logical Processing Order.
Ja, das ist auch im SQL-Standard so definiert.
Da ist SELECT hinter HAVING. Allerdings scheint es MySQL tatsächlich anders zu halten, da steht ausdrücklich dass man Aliasnamen aus SELECT im HAVING verwenden darf.
Der Zettelkasten verhält sich hier also mal wieder nicht standard-gerecht, welch Überraschung. Der IE der Datenbanksysteme.
LG,
CK-
Tach!
Da ist SELECT hinter HAVING. Allerdings scheint es MySQL tatsächlich anders zu halten, da steht ausdrücklich dass man Aliasnamen aus SELECT im HAVING verwenden darf.
Der Zettelkasten verhält sich hier also mal wieder nicht standard-gerecht, welch Überraschung. Der IE der Datenbanksysteme.
Und was ist daran jetzt schlecht, außer dass es der Standard anders sieht? Und jetzt sag nicht Migrationsprobleme, so oft migriert man nicht, dass das ins Gewicht fällt (gemäß Statistik der gefühlten Werte).
dedlfix.
-
Hallo dedlfix,
Und was ist daran jetzt schlecht, außer dass es der Standard anders sieht?
Ja, was ist schlecht daran sich nicht an Standards zu halten? Standards sind ne bescheuerte Idee, wir machen einfach alle unser eigenes Süppchen und scheissen auf Interoperabilität. 👍
LG,
CK-
Tach!
Und was ist daran jetzt schlecht, außer dass es der Standard anders sieht?
Ja, was ist schlecht daran sich nicht an Standards zu halten? Standards sind ne bescheuerte Idee, wir machen einfach alle unser eigenes Süppchen und scheissen auf Interoperabilität. 👍
Du kannst doch standardgerechte Querys auch mit MySQL fabrizieren, wenn dir danach ist. Ein Standard heißt doch nicht, dass man die Welt darauf einengen muss.
dedlfix.
-
Hallo dedlfix,
Du kannst doch standardgerechte Querys auch mit MySQL fabrizieren, wenn dir danach ist. Ein Standard heißt doch nicht, dass man die Welt darauf einengen muss.
Das ist im Prinzip zwar richtig, aber Erweiterungen, die dafür sorgen, dass grundlegende Annahmen (die durchaus auch Performance-relevant sind) nicht zutreffen, sind schlechte Erweiterungen. Dieser Fall ist hier gegeben. Stichwort correlating subquery - bei allen DBMS kann ich davon ausgehen, dass der performance hit abhängig vom letztlichen result set ist. Ausser bei MySQL, denn hier müssen offensichtlich erst die column list expressions ausgewertet werden. Und nicht nur das, ich laufe hier sogar in eine Irreführung hinein, da das Verhalten abweichend von der Definition ist.
LG,
CK-
Tach!
Und nicht nur das, ich laufe hier sogar in eine Irreführung hinein, da das Verhalten abweichend von der Definition ist.
Wessen Definition? Der des Standards. Und hat MySQL behauptet ein System der Definition gemäß zu sein? MySQL hat jedenfalls eine Dokumentation, in der diese und andere Verhaltensweisen dokumentiert sind, (zumindest teilweise) auch mit Hinweis auf die Abweichung vom Standard und wie man standardgerechtes Verhalten durch Konfigurationsänderung erzwingen kann (GROUP BY und nicht gruppierte Felder). Irreführung setzt meiner Meinung nach Vorsatz voraus. Den kann ich nicht erkennen. Wenn du selbst in die Irre läufst, weil du dir das Lesen der Dokumentation sparst, solltest du dabei nicht anderen die Schuld geben. Als Wanderer zwischen den Welten muss man mit Unterschieden rechnen. "Es gibt einen Standard, was kann mir da schon passieren?" ist eine recht leichtfertige Einstellung.
dedlfix.
-
Hallo dedlfix,
Und nicht nur das, ich laufe hier sogar in eine Irreführung hinein, da das Verhalten abweichend von der Definition ist.
Wessen Definition? Der des Standards. Und hat MySQL behauptet ein System der Definition gemäß zu sein?
MySQL behauptet, ein „relational SQL DBMS” zu sein. Und für SQL gibt es einen Standard.
Irreführung setzt meiner Meinung nach Vorsatz voraus.
Man kann ein Feature nicht ohne Vorsatz abweichend vom Standard implementieren. Entweder ich scheisse auf den Standard und schaue gar nicht erst nach, wie der es definiert oder ich weiche trotz dieses Wissens davon ab. Beide Fälle laufen unter Vorsatz.
Den kann ich nicht erkennen. Wenn du selbst in die Irre läufst, weil du dir das Lesen der Dokumentation sparst, solltest du dabei nicht anderen die Schuld geben. Als Wanderer zwischen den Welten muss man mit Unterschieden rechnen. "Es gibt einen Standard, was kann mir da schon passieren?" ist eine recht leichtfertige Einstellung.
Ja, wie gesagt, Standards sind scheisse, Interoperabilität wird überbewertet.
Es ist mir schleierhaft, warum man sich über die schlechte oder fehlerhafte Unterstützung der W3-Standards beschweren kann aber das bei SQL völlig Ok findet.
Aber wie auch immer, ich habe weder Zeit noch Lust das weiter auszuführen, wenn du das OK findest sei dir das unbenommen, wir beide ändern da eh nichts. Ich für meinen Teil halte derartiges Abweichen vom Standard allerdings für schädlich und gefährlich. Ein weiterer Grund MySQL zu meiden.
LG,
CK-
Tach!
MySQL behauptet, ein „relational SQL DBMS” zu sein. Und für SQL gibt es einen Standard.
Zumindest das GROUP-BY-Verhalten kann man auf Standardkonformität konfigurieren. Wenn man ein System als nicht-standardkonform bezeichnet, weil darin Dinge enthalten sind, die zusätzlich zum Standard implementiert sind, dann sind alle anderen DBMSe auch nicht standardkonform.
Irreführung setzt meiner Meinung nach Vorsatz voraus.
Man kann ein Feature nicht ohne Vorsatz abweichend vom Standard implementieren. Entweder ich scheisse auf den Standard und schaue gar nicht erst nach, wie der es definiert oder ich weiche trotz dieses Wissens davon ab. Beide Fälle laufen unter Vorsatz.
MS-SQL, Oracle und sicher auch PostgreSQL weichen vom Standard ab, indem sie zusätzliche Dinge implementieren. Und das vorsätzlich. Sie führen also irre.
Ja, wie gesagt, Standards sind scheisse, Interoperabilität wird überbewertet.
Es ist mir schleierhaft, warum man sich über die schlechte oder fehlerhafte Unterstützung der W3-Standards beschweren kann aber das bei SQL völlig Ok findet.
Ich habe mich nicht beschwert. Dieser scheinbare Gegensatz trifft auf mich nicht zu.
Bei den W3-Standards ist die Sachlage auch noch mal gehörig anders. Denn da ist es an der Tagesordnung, dass man mit einer Quelle sehr viele Systeme versorgt. Die Notwendigkeit der Interoperabilität von SQL-Statements hingegen ist deutlich seltener gegeben. Wie oft wechselt man das DBMS? Oder schreibt Software, die auf diversen DBMSen laufen muss, und das dann ohne Abstraktionslayer?
Aber wie auch immer, ich habe weder Zeit noch Lust das weiter auszuführen, wenn du das OK findest sei dir das unbenommen, wir beide ändern da eh nichts. Ich für meinen Teil halte derartiges Abweichen vom Standard allerdings für schädlich und gefährlich. Ein weiterer Grund MySQL zu meiden.
Ob ich das ok finde, sei mal dahingestellt, ich bin nur nicht mit deinen Argumenten einverstanden.
dedlfix.
-
Hallo dedlfix,
Ob ich das ok finde, sei mal dahingestellt, ich bin nur nicht mit deinen Argumenten einverstanden.
Das musst du ja auch nicht. Ich bin es ja mit deinen auch nicht. :-)
LG,
CK
-
-
-
-
-
-
-
-
-
-
-