Ja, was haben wir denn da.
Keine Ahnung, wars wirklich angefordert?
hast du den beitrag von hauke eigentlich gelesen, worum es geht ? dort steht es schwarz auf weiß geschrieben, also was soll das ?
"Hauke" stört sich am Mehrfach-JOIN, Dein Beitrag intonierte die "n:m". Hast Du da was nicht verstanden? Sollen wirs erklären? Gerne!
Du wiederholst Dich, wir lieferten ahlt die "Komplettlösung".
selbst wenn du die abfrage auf einen betreiber einschränkt, bekommst du immer noch vier ergebnisdatensätze. wenn du ihren beitrag mal lesen würdest (bekomme immer mehr den anschein, dass du das nicht getan hast), dort steht ein ergebnisdatensatz, den sie bekommen möchte explizit drinne. du lieferst also keine komplettlösung, sondern eine falsche.
Häh?
uns ging es darum zu zeigen, dass es nicht erforderlich ist, Dubletten auszuschliessen, denn es gibt im Beispiel keine.
denn unsinn deiner aussage kannst du aber selber nicht verstehen oder ? wenn es gar keine dubletten geben kann, wie du selber sagst, warum zum teufel willst du dann mit union auf doubletten prüfen ? ich meine , das ist doch recht einfach zu verstehen, dass ein union dort überflüssig ist und unnötige operationen dem dbms abzwingt. es gibt keine doubletten, aber du prüfst auf doubletten. sag mir doch mal einen grund, worin darin der sinn besteht ?
Häh? - Bitte ggf. Fragen stellen.
[Gesülze]... probiere es einfach aus, dann haben wir gewissheit.
;)
Gut, die Aliasnamen sind unzureichend spezifiziert. Die Schreibweisen sehr unschön, gar laienhaft. ;)
kannst du mir bitte einen syntaktischen fehler in meiner abfrage nennen, welche nach deinen behauptungen vorhanden sein sollen ?
Schau Dir doch mal die Alias-Tabellennamen an in Deinem Beispiel:
Was ist "u"?
In letzter Zeit kommst Du mir auf die ganz Doofe. Aber no prob, wir helfen gerne. :)
Also, noch einmal ganz klar fürs Archiv und so:
- eine Lösung ist der Vierfach-JOIN auf Unternehmen
- eine Lösung ist der multiple Sub-SELECT per Subabfrage
- eine ("die" ;) Lösung ist der einfach-JOIN per intelligente Sub-Abfrage