Abfrage: Kund hat Artikel X aber nicht Y gekauft

[Delphi.Narium]

Zitat von Uwe Raabe:

Zitat von Delphi.Narium:

Aber damit ist die Vermutung widerlegt:

Nicht zwingend.

Deshalb schrieb ich ja später auch

Zitat von Delphi.Narium:

Es geht also doch

Zitat von Uwe Raabe:

SQL-Code:

SELECT K.KdNr, K.Name
FROM Kunden K
INNER JOIN Rechnungen R ON K.KdNr = R.KdNr
LEFT JOIN Positionen P1 ON R.ReNr = P1.ReNr AND P1.Artikel = 4701
LEFT JOIN Positionen P2 ON R.ReNr = P2.ReNr AND P2.Artikel = 5702
GROUP BY K.KdNr, K.Name
HAVING COUNT(P1.ReNr) > 0 and COUNT(P2.ReNr) = 0;

Das ist eine Abwandlung/Weiterentwicklung der von der KI weiter oben gelieferten Antwort oder hat zumindest große Ähnlichkeit mit ihr. Sie hat den Vorteil, dass sie ohne Case und Sum auskommt und sie ist dadurch deutlich eleganter und lesbarer (und vermutlich bei größeren Datenmengen auch schneller).

Zitat von Uwe Raabe:

Allerdings lassen die nur rudimentär vorhandenen Testdaten eigentlich keine belastbare Aussage zu.

Das war für mich auch das Hauptproblem erstmal Testdaten zu erstellen, die wirklich alle möglichen Fälle abdecken, hoffe aber, dass mir das in https://www.delphipraxis.net/1535576-post20.html gelungen ist.

Interessant ist: Wir haben jetzt acht unterschiedliche und funktionierende Lösungen zur Aufgabenstellung.

[Uwe Raabe]

Zitat von Delphi.Narium:

Das ist eine Abwandlung/Weiterentwicklung der von der KI weiter oben gelieferten Antwort oder hat zumindest große Ähnlichkeit mit ihr.

In der Tat. Ich muss den Part deiner Antwort irgendwie überlesen haben, sonst hätte ich mich darauf bezogen. Sorry!

[IBExpert]

so als technische basisinfo noch:

ein sum befehl wird immer die komplette ergebnismenge abklappern, spricht, wenn
du tausend kunden hast die alle je 1000 rechnungen mit dem verkauften produkt hatten,
kommt der server nicht drumherum, alle eine Million datensätze zu analysieren, um die komplett
unwichtige Information der summe zu ermitteln (war ja im threadtitel irrelevant).

Ein exists ist zumindest bei firebird so implementiert, das dieser sobald ein record
in der ergebnismenge gefunden wurde (bei der hoffentlich passende indizes nutzbar sind)
sofort die weiteren teilergebnisse ignoriert, also in dem o.a. fall mit passenden indizes
statt 1000000 operationen das ergebnis mit 1000 operationen ermitteln kann.

Bei single user datenbanken wird das kaum keiner merken, wenn aber dutzende oder hunderte user
solche abfragen in schlechter version parallel machen und so ermittelte unwichtige count
oder sum befehle auf einem Startscreen einer Applikation darstellt, dann wird der server
niemals performant sein, weil der immer nur schwachsinn mit mörderaufwand treibt.

wenn dann noch dazu kommt, das die 1000000 rechnungen und die 1000 kunden nicht über passende
indizes verfügen, reden wir auch intern nicht über 1000000 operationen sondern schnell mal über
1000000000 operationen.

firebird liefert sehr gute hilfsmittel um so was für die eigenen SQLs zu erkennen, aber das
Design der eigenen SQLs muss der programmierer verantworten. Wenn man eine summe brauchen würde
geht es nicht anders, aber aus der summe >= eigentlich nur die existenz auszuwerten ist
um es mal freundlich zu sagen unglücklich programmiert.