MySQL max

[mixmastertobsi]

Hallo, ich versuche mich gerade an eine SQL Abfrage, bei welcher der höchste Preis ausgegeben werden soll.

Die Tabellen sind wie folgt

Tabelle 1

Artikelnr | Produkte
----------------------
1         | Produkt1
2         | Produkt2
3         | Produkt3

Tabelle 2

Attributnr | Artikelnr | Bezeichnung | Preis
---------------------------------------------
1          | 1         | Attribut1   | 9.99
2          | 1         | Attribut2   | 119.00
3          | 1         | Attribut3   | 20.00
4          | 2         | Attribut4   | 39.99
5          | 2         | Attribut5   | 219.00
6          | 3         | Attribut6   | 80.00

Wie folgt Frage ich die Daten ab
SELECT tabelle2.preis FROM tabelle1 JOIN tabelle2 ON tabelle2.artikelnr=tabelle2.artikelnr

Ausgabe
9.99
39.99
80.00

Nun möchte ich den MAX Preis von allen Zeilen ausgeben
SELECT MAX(tabelle2.preis) FROM tabelle1 JOIN tabelle2 ON tabelle2.artikelnr=tabelle2.artikelnr

Eigentlich sollte nun der Preis 80.00 ausgegeben werden. In der Ausgabe erscheint jedoch der Preis 219.00.

Was mache ich denn da falsch?!?

[Cheatah]

Hi,

Wie folgt Frage ich die Daten ab
SELECT tabelle2.preis FROM tabelle1 JOIN tabelle2 ON tabelle2.artikelnr=tabelle2.artikelnr

Du solltest etwas sorgfältiger mit Copy&Paste umgehen, besonders wenn Du danach noch Daten änderst. Dieser Join ist reichlich sinnlos; und selbst wenn ich ihn gedanklich korrigiere, führt das Statement mit den von Dir gezeigten Daten nicht zur behaupteten Ausgabe.

Was mache ich denn da falsch?!?

Du nennst nicht funktionierende Beispiele.

Cheatah

[mixmastertobsi]

OK - ich habe eigentlich versucht es verständlich zu erklären.

Warum macht dieser JOIN keinen sein. OK - im Beispiel habe ich was vergessen

SELECT tabelle2.preis FROM tabelle1 JOIN tabelle2 ON tabelle2.artikelnr=tabelle2.artikelnr GROUP BY tabelle1.artikelnr

Mein Ziel ist es, den höchsten Wert aus allen Zeilen auszugeben.

[<mad>]

hey,

faellt dir daran was auf?

tabelle2.artikelnr=tabelle2.artikelnr

gruss

[<mad>]

vergiss es, ich kann nicht mehr klar denken ;)

gruss

[mixmastertobsi]

Die Abfrage lautet natürlich wie folgt

SELECT tabelle2.preis FROM tabelle1 JOIN tabelle2 ON tabelle2.artikelnr=tabelle1.artikelnr GROUP BY tabelle1.artikelnr

[DiBo33]

http://jan.kneschke.de/projects/mysql/groupwise-max/

[Cheatah]

Hi,

SELECT tabelle2.preis FROM tabelle1 JOIN tabelle2 ON tabelle2.artikelnr=tabelle1.artikelnr GROUP BY tabelle1.artikelnr

ich bin immer wieder enttäuscht von MySQL, wenn nicht schlicht und ergreifend ein Fehler ausgespuckt wird, sobald man eine Gruppierung einsetzt und Spalten selektiert, nach denen nicht gruppiert wird. Bei so etwas *kann* nur ein rein zufälliges Ergebnis rauskommen.

Welcher der in Frage kommenden Ergebnis-Datensätze muss denn Deiner Ansicht nach hier aus der Gruppierung herauspurzeln, und warum bestehst Du auf diesen und nicht auf einen anderen? Wenn Du es für legitim hältst, dass der Datensatz mit preis=80.00 gewählt wird, warum ist es dann illegitim, dass bei einer Umformulierung des Statements der mit preis=219.00 kommt? Immerhin suchst Du nach einem Maximum, dann ist es doch eigentlich nett von MySQL, dass hier über den Zufall hinaus auch tatsächlich der Maximalwert genommen wird.

Cheatah

[dedlfix]

Hi!

ich bin immer wieder enttäuscht von MySQL, wenn nicht schlicht und ergreifend ein Fehler ausgespuckt wird, sobald man eine Gruppierung einsetzt und Spalten selektiert, nach denen nicht gruppiert wird. Bei so etwas *kann* nur ein rein zufälliges Ergebnis rauskommen.

Works as designed und documented. Wichtig für den breiten Erfolg eines Systems ist nicht nur der Preis, sondern auch, dass es sich einfach anwenden lässt. Dazu gehört auch, dass man bei manchen Dinge einfach mal nicht die anderenorts übliche Strenge walten lässt. Wenn du deine eigenen Enttäuschungen vermeiden willst: SET sql_mode='ONLY_FULL_GROUP_BY';

Lo!

[Cheatah]

Hi,

ich bin immer wieder enttäuscht von MySQL, wenn nicht schlicht und ergreifend ein Fehler ausgespuckt wird, sobald man eine Gruppierung einsetzt und Spalten selektiert, nach denen nicht gruppiert wird. Bei so etwas *kann* nur ein rein zufälliges Ergebnis rauskommen.
Works as designed und documented.

das ändert nichts daran, dass es meiner Meinung nach ein Designfehler ist.

Wichtig für den breiten Erfolg eines Systems ist nicht nur der Preis, sondern auch, dass es sich einfach anwenden lässt.

Richtig. Ich halte es bisweilen für einfacher, wenn einem Fehler genannt werden, anstatt dass "trotzdem irgendwas passiert". Sie wegzudefinieren ändert nichts daran, dass es Fehler sind.

Dazu gehört auch, dass man bei manchen Dinge einfach mal nicht die anderenorts übliche Strenge walten lässt.

Die Wege, die zu Erfolg führen, sind nicht allein durch diesen Erfolg schon verziehen.

Wenn du deine eigenen Enttäuschungen vermeiden willst: SET sql_mode='ONLY_FULL_GROUP_BY';

Für mich selbst habe ich keine Enttäuschungen, weil ich dieses "Feature" schlicht und ergreifend nicht nutze. Es enttäuscht mich, dass *andere* die zweifelhafte Chance haben, in die Falle zu tappen.

Cheatah

[dedlfix]

Hi!

Works as designed und documented.
das ändert nichts daran, dass es meiner Meinung nach ein Designfehler ist.

Kommt auf die Zielstellung an.

Richtig. Ich halte es bisweilen für einfacher, wenn einem Fehler genannt werden, anstatt dass "trotzdem irgendwas passiert". Sie wegzudefinieren ändert nichts daran, dass es Fehler sind.

Ist es denn (immer) ein Fehler? Wenn die Daten nicht normalisiert vorliegen, ist das Wählen eines beliebigen Wertes aus den redundanten genau das erwartete Ergebnis. Damit ist es kein Fehler aus der Sicht dieses Anwenders. Es ist auch kein Fehler, Daten nicht immer normalisiert vorliegen zu haben. Beispielsweise kann es performancegünstiger sein, Daten bewusst redundant in einer Tabelle liegen zu haben als immer Joinen zu müssen. Und in solch einem Fall ist das Wählen von nicht gruppierten Feldern auch kein Problem.

Dazu gehört auch, dass man bei manchen Dinge einfach mal nicht die anderenorts übliche Strenge walten lässt.
Die Wege, die zu Erfolg führen, sind nicht allein durch diesen Erfolg schon verziehen.

Das klingt so generös, als ob es nur eine maßgebliche Stelle gäbe, die Festlegungen treffen und Abweichungen bewerten darf.

Für mich selbst habe ich keine Enttäuschungen, weil ich dieses "Feature" schlicht und ergreifend nicht nutze. Es enttäuscht mich, dass *andere* die zweifelhafte Chance haben, in die Falle zu tappen.

Mich enttäuschte dann eher, dass sie (Handbuch lesen sie ja sowieso nicht) nicht selbst erkennen, dass bei nicht redundanten Daten die Auswahl eines solchen Felder ein Problem darstellt.

Lo!

[Cheatah]

Hi,

Works as designed und documented.
das ändert nichts daran, dass es meiner Meinung nach ein Designfehler ist.
Kommt auf die Zielstellung an.

die Zielstellung ist zunächst einmal ein DBMS herzustellen.

Ist es denn (immer) ein Fehler?

Nein. Es ist *allgemein* ein Fehler, da keine deterministischen Ergebnisse gewährleistet sind. Wenn das Datenbank-Layout dies übernimmt, spricht nichts dagegen, dass für diesen Einzelfall eine Lösung bereit gestellt wird. Ob diese automatisiert aktiv werden kann, möchte ich gerade nicht untersuchen, zumal im aktuellen Fall das Datenbank-Layout ganz offenkundig nichts zur Problemlösung beiträgt. Im Zweifel könnte der SQL-Dialekt die Möglichkeit vorsehen, einen Hint anzugeben, dass es genügt, den ersten gefundenen Datensatz (als Beispiel) zu verwenden. Ohne etwas Derartiges ist es, meiner Meinung nach, bar jedweden Zweifels ein live-kritischer Bug der Software, wenn in dieser Situation keine Fehlermeldung geschmissen wird.

Wenn die Daten nicht normalisiert vorliegen, ist das Wählen eines beliebigen Wertes aus den redundanten genau das erwartete Ergebnis.

Die Daten sind nicht redundant. Das Statement ergibt über den gruppierten Wert unterschiedliche Datensätze. Fehler.

Damit ist es kein Fehler aus der Sicht dieses Anwenders.

Doch, sonst hätte der Anwender seine Frage nicht gestellt. Er erhält nicht das Ergebnis, das er erwartet hat, weil sein DBMS kurz gesagt "irgendwas" liefert, nicht jedoch das, was es liefern soll.

Es ist auch kein Fehler, Daten nicht immer normalisiert vorliegen zu haben.

Ich sehe die Normalisierung nicht als Teil des aktuellen Problems an.

Die Wege, die zu Erfolg führen, sind nicht allein durch diesen Erfolg schon verziehen.
Das klingt so generös, als ob es nur eine maßgebliche Stelle gäbe, die Festlegungen treffen und Abweichungen bewerten darf.

Vor allem klingt es so, als ob der Zweck doch nicht alle Mittel heiligt.

Mich enttäuschte dann eher, dass sie (Handbuch lesen sie ja sowieso nicht) nicht selbst erkennen, dass bei nicht redundanten Daten die Auswahl eines solchen Felder ein Problem darstellt.

Ja. Ich habe hierfür jedoch eher Verständnis, weil die Nichterkenntnis bei Unerfahrenen vorliegt, im Gegensatz zu erfahrenen Leuten wie z.B. die Verantwortlichen für die Funktionsweise von MySQL.

Cheatah

[dedlfix]

Hi!

Wenn die Daten nicht normalisiert vorliegen, ist das Wählen eines beliebigen Wertes aus den redundanten genau das erwartete Ergebnis.
Die Daten sind nicht redundant. Das Statement ergibt über den gruppierten Wert unterschiedliche Datensätze. Fehler.

Entschuldigung, ich hätte es besser herausstellen sollen, dass ich für die Diskussion um dieses Verhalten nicht den Fall von mixmastertobsi meinte, sondern einen, in dem man das Feature problemlos verwenden kann.

Mich enttäuschte dann eher, dass sie (Handbuch lesen sie ja sowieso nicht) nicht selbst erkennen, dass bei nicht redundanten Daten die Auswahl eines solchen Felder ein Problem darstellt.
Ja. Ich habe hierfür jedoch eher Verständnis, weil die Nichterkenntnis bei Unerfahrenen vorliegt, im Gegensatz zu erfahrenen Leuten wie z.B. die Verantwortlichen für die Funktionsweise von MySQL.

Unerfahrenheit ist keine Entschuldigung für Nicht-Nachdenken. Wenn es eine Funktionalität gibt, die Daten zusammenfasst, dann sollte man, wenn man die Ambition hat programmieren zu wollen, auch mit einfachem Nachdenken drauf kommen, dass es ein Verfahren geben muss, das einen einzelnen Wert daraus auswählt. Nun könnte man sich überlegen, wie denn das Verfahren wissen kann, welchen Wert ich will. Und damit kann man nun weitere Recherchen führen, die zum Erkenntnisgewinn beitragen können.

Lo!

[Ilja]

moin,

Unerfahrenheit ist keine Entschuldigung für Nicht-Nachdenken.

ich will/muss mich hier auf die seite von Cheatah schlagen. man kann die praxis nicht einfach mit einem verweis auf die doku wegschieben. ich muss schon die vorteile gegen die nachteile abwägen und vor allem, es ist unnötig. es geht dabei um reine performace gründe, warum mysql diesen weg gegangen ist und da hat Cheatah recht, das sollte auf seiten des dbms gelöst werden und nicht durch die anwender, die es nur verwirrt. es ist und bleibt ein bug für mich und nicht ein feature.

Ilja

[MudGuard]

Hi,

Works as designed und documented.

mag sein.

Wichtig für den breiten Erfolg eines Systems ist nicht nur der Preis, sondern auch, dass es sich einfach anwenden lässt.

Überraschende Ergebnisse (aus den nicht-Gruppierten Spalten wird ein Wert nicht-vorhersehbar ausgewählt) halte ich nicht für einfach in der Anwendung.

Und daß dieses Mysql-"Feature" durchaus Probleme hat, sieht man hier ja immer wieder, weil immer wieder nachgefragt wird, warum hier der Spaltenwert nicht aus der erwarteten Zeile (z.B. aus der mit dem MAX(spalte)) genommen wird ...

SET sql_mode='ONLY_FULL_GROUP_BY';

Schön, daß das Verhalten einstellbar ist.
Aber: die Voreinstellung ist aus meiner Sicht falsch - das überraschende Verhalten sollte nicht abschaltbar sein, sondern sollte für den, der es wirklich haben will, einschaltbar sein.

cu,
Andreas

[Vinzenz Mai]

Hallo,

Mein Ziel ist es, den höchsten Wert aus allen Zeilen auszugeben.

dafür ist der Join völlig überflüssig und es ist offensichtlich, dass der höchste Wert

219.00

ist, was größer ist als

80.00

Das Ergebnis ist daher völlig erwartungsgemäß und Du erhieltest es auch aus der wesentlich einfacheren Abfrage:

SELECT  
    MAX(Preis)  
FROM  
    tabelle2  

Warum erwartest Du 80.00 als Ergebnis?

Freundliche Grüße

Vinzenz