nicht angemeldet
Hallo !
das kommt drauf an, wieviele daten sich in den beiden tabellen befinden.
Ach was !
die anzahl der datensätze der beiden tabllen miteinander multipliziert ergibt die summe des ergebnisses eines kreuzproduktes (jeder mit jedem).
Potzblitz !
Na dann 'lass uns mal sehen :
2 Datensaetze sind in A
A#1 wird auf 3 Saetze auf B abgebildet.
A#2 auf 2 Saetze aus B.
=> 5 Saetze in B, denn wen sollten die restlichen B-Datensaetze wohl referenzieren ?
( + ? mit NULL FK's aber in Anbetracht der Benennung der
FK - Feldes gehe ich davon aus, dass es NOT NULL ist )
=> 2*5 = 10 beim kartesischen Produkt.
Hatte ich nicht genau das geschrieben ?
Liegt das nicht eher daran, dass in dem SELECT nur Felder der unabhaengigen Tablle stehen ?
nein, es liegt daran, dass die spaltenausgaben bei DISTINCT genau den spalten entspricht, über die du auch gruppieren würdest.
Ja, namelich alle aus A, der unabhaengigen Tabelle der Relation. Was ich ja bereits geschrieben hatte.
und dabei ist es egal, aus welcher tabelle die spalten kommen.
Das stimmt nicht. Wenn aus B, wovon man ausgehen muss, verschiedene B-Werte for einen A-Datensatz mitselektiert wuerden, waeren die Rows ggf. DISTINCT auch wenn A.id und A.name doppelt auftraeten.
GROUP BY ( und DISTINCT, was implizit GROUP BY verwendet ) sortiert naemlich hier implizit mit. Da ein String-Feld mit drin ist , koennte das evtl teuer werden- wie teuer haengt davon ab ob das Feld indiziert ist.
jede GROUP BY oder DISTINCT Anweisung sind letztlich nur sortierungen.
Stimmt nicht. Zum Suchen brauch ich n, zum Sortieren n*log(n) Operationen. Auch in der Doku steht was zum diesbezueglichen
Overhead.
Gute Nacht !
Holger