Philipp Hasenfratz: Query an mehrere Tabellen

Beitrag lesen

Halihallo Ilja

auf der anderen seite, ist es fraglich, dass genau diese konstellation existiert, wenn auch nicht unmöglich. laut bernds aussagen ist nur x.id pk. insofern würde ich eher zu nein, bzw. da alle den namen id haben, eher zu allen drei als pk tendieren. wobei es sicherlich auch um FK handeln kann. who knows....

Deswegen habe ich Bernd darauf angesprochen um selber sicher zu
gehen und er hat in https://forum.selfhtml.org/?t=94762&m=573809 geantwortet. Aus diesem
Posting lese ich, dass x.id und y.id unique sind und z.id hingegen
mehrfach vorkommt. Also genau diese Konstellation auf die ich mich
(seit dem Posting von Bernd) stets beziehe und mit GROUP BY lösbar
ist.

wobei mein 0 sonderfall mir wieder ins gedächnis gekommen ist. count(*) liefert immer einen wert, der aber im sonderfall auch 0 sein kann, nämlich wenn die ergebnis-tabelle leer ist.

Stopp mein geschätzter Columbo :-) Wenn ich mich kurz zittieren darf:
<cite>
wenn alle beteiligten Join-Relationen mit PRIMARY KEY, oder
Schlüsselkandidat (UNIQUE) in GROUP BY aufgenommen werden, macht
jedwelcher COUNT(*) keinen Sinn, da er per Definition *immer* 1 ist.
</cite>

Ich spreche von COUNT(*) nach einem GROUP BY. Es ist richtig, dass
bei einer leeren Ergebnisrelation COUNT(*) *ohne* GROUP BY beim
SELECT, 0 ausgibt. Aber bei einem GROUP BY ist die gesamte
Ergebnisrelation eine Empty-Set und es wird gar nix ausgegeben, also
auch kein COUNT(*)==0, sondern eben einfach ein Empty-Set. Sobald die
Ergebnisrelation nach einem GROUP BY eben kein Empty-Set ist, wirst
du nie COUNT(*) mit 0 antreffen, da Gruppierungen nach den Primary
Keys die keine Übereinstimmung finden gar nicht erst beim Join aus-
gegeben werden, somit nicht gruppiert werden und somit auch kein
COUNT(*)==0 auftreten kann.

Anders formuliert: Wenn du einen Join über zwei Relationen hast,
werden nur Tupel ausgegeben, die auf eine bestimmte Selektion
zutreffen; solche Tupel die nicht zutreffen (also keinen Join-Partner
in der anderen Relation finden => wo eben COUNT(*)==0 wäre), sind
gar nicht erst in der Ergebnisrelation bei welcher du GROUP BY
anwendest, somit wurde durch den JOIN schon jedwelche Möglichkeit ein
COUNT(*)==0 zu erreichen ausgeschlossen, da der JOIN nur aufgrund
der Selektion gültige Join-Partner zulässt und somit auch mindestens
ein Join-Partner in der anderen Relation haben. Eine Ausnahme bilden
hier die OUTER JOIN's, wo eben auch Join-Paare gebildet werden, wenn
auf der anderen Seite kein Partner gefunden wird, hier kann
COUNT(attr)==0 wirklich vorkommen, da aber COUNT(*) stupfsinnig die
Anzahl Tupel zählt, werden auch Tupel mit NULL-Werten gezählt.

Hm. Ich habe Probleme das irgendwie verständlich zu formulieren.
Zusammenfassend: Bei einem GROUP BY gibt ein COUNT(*) immer
mindestens eins aus, da sonst nach nix gruppiert geworden wäre und
das steht im Wiederspruch zur Definition was GROUP BY macht.
=> Paradoxon.

Viele Grüsse

Philipp