Das funktioniert nur, weil MySQL nicht erkennt, daß die Abfrage logisch falsch ist, und liefert nur zufällig ein (vielleicht) richtiges Ergebniss. Du hast 3 Spalten im Resultat, davon eine aggregiert, also die max() - Funktion. Daher müssen alle anderen Spalten gruppiert werden - was Du nicht tust. Aktuelle MySQL-Versionen sowie ALLE ANDEREN DATENBANKEN akzeptieren diesen Fehler nicht. Deine 'Lösung' basiert also auf der Ausnutzung eines bis jetzt nicht gefixten Bugs. Viel Spaß damit!
Ankündigung
Einklappen
Keine Ankündigung bisher.
SQL Abfragen für API
Einklappen
Neue Werbung 2019
Einklappen
X
-
Das ist natuerlich kacke. Vielen Dank fuer den Hinweis. Heisst das ich muss die beiden Spalten, die ich nicht aggregiere in das GROUP BY packen:
PHP-Code:WITH v_table AS
(select item, count(item) as v_amount from fruit_basket group by item)
SELECT price_list.item, v_table.v_amount, MAX(price_list.total_price) AS total_price FROM v_table
JOIN price_list ON price_list.item = price_list.item
WHERE price_list.item IN (v_table.item) AND price_list.amount <= v_table.v_amount GROUP BY price_list.item, v_table.v_amount;
Kommentar
-
Ach übrigens danke für den Tipp mit den CTEs. Es hat zwar ein bisschen gedauert, aber ich hab das Funktionsprinzip so langsam verstanden. Mein Problem ist jetzt gelöst, aber ich versuche jetzt aus Spaß das Ganze so zu verschachteln, dass ich exakt das rauskriege was ich will. Ist auf jeden Fall spannend
Kommentar
-
ja, CTE's sind cool. Man kann damit auch rekursive Abfragen machen, und PostgreSQL kann auch writeable CTE (damit kann man zB. bei einem INSERT eine vergebene ID gleich für weitere INSERT's verwenden, man kann also mit einem einzigen SQL-Statement gleichzeitig in mehreren Tabellen ein Insert oder auch Update machen und spart sich dabei mehrere Gänge zur Datenbank). Allerdings können CTE's auch verdeckte Performance-Fallen sein - PostgreSQL optimiert solche Abfragen erst wirklich ab Version 12, vorher wurden CTE's immer erst komplett materialisiert. Da hab ich arge Performance-Probleme schon bei Kunden aufgedeckt ...PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Kommentar
-
Ja das mit der Performance hab ich mir schon gedacht. Ich werde den Teil auch definitiv doch die Entwickler machen lassen und wenn es ineffizient ist muessen wir damit leben. Das hab ich immerhin aus dem Ganzen gelernt. Dafür sind diese Abfragen zu komplex (für mich) und zu fehleranfällig. Sollte das Projekt größer werden muss eh alles ordentlich von Profis überarbeitet werden, da kann ich absolut nix mehr machen.
Aber am Ende gings mir um den puren Ehrgeiz die Ausgabe exakt so zu haben wie ich sie wollte. Es mag natürlich kompliziert sein, aber ich habe es geschafft. Das ist definitiv cool
Kommentar
-
Obskurer Thread hier. Firmengründung, App, bis zu 60 Datenbank-Abfragen (pro Request?!) und einen Verantwortlichen, der selber jetzt nicht so fit im Datenbank-Handling ist, aber seinen Entwicklern quasi den Code schreibt...
Da finde ich protestix in #9 noch am hilfreichsten:Das geht aber schon tief ins Geschehen, ich dachte dafür haste Programmierer, lass die das machen.
[B]Es ist schon alles gesagt. Nur noch nicht von allen.[/B]
Kommentar
-
Zitat von Dsdxb Beitrag anzeigenDas ist natuerlich kacke. Vielen Dank fuer den Hinweis. Heisst das ich muss die beiden Spalten, die ich nicht aggregiere in das GROUP BY packen:
PHP-Code:WITH v_table AS
(select item, count(item) as v_amount from fruit_basket group by item)
SELECT price_list.item, v_table.v_amount, MAX(price_list.total_price) AS total_price FROM v_table
JOIN price_list ON price_list.item = price_list.item
WHERE price_list.item IN (v_table.item) AND price_list.amount <= v_table.v_amount GROUP BY price_list.item, v_table.v_amount;
- 1 Likes
Kommentar
Kommentar