Hallo zusammen,

Ich habe 3 Tabellen:
TabelleA
TabelleB: Bindeglied zwischen TabelleA und TabelleC
TabelleC

Zu jedem TabelleA-Datensatz können mehere TabelleC-Datensätze gehören.
Ein TabelleC Datensatz kann aber auch zu mehrere TabelleA-Datensätze gehören

Nun mein Vorhaben:
Select tabelleA.spalteX, (...) from TabelleA join TabelleB on TabelleB.tabA = TabelleA.id join TabelleC on TabelleC.id = TabelleB.tabC where TabelleC.wert = 'beispiel'

In TabelleC existierten mehrere Datensätze mit der Spalte wert = 'beispiel'.

Das Problem ist nun, dass bei einer Abfrage, einige Datensätze (TabelleA) mehrmals zurückgegeben werden. Ein distinct geht sehr zu lasten der Performance-> möchte ich nicht.

Ich denke mal man muss irgendwas an den Join's ändern, nur weiss ich nicht genau was, habe mir vorher damit gleich den mySQL-Server zerschossen

Hat jemand einen Tipp?

Vielen Dank
Adrian

Kannst Du nicht die konkrete query und Beispieldatensätze posten, würde es enorm vereinfachen.
Lesestoff: http://dev.mysql.com/doc/refman/5.1/de/dis...timization.html
Evtl. reicht einfach left join, aber ich mag das Beispiel so nicht anschauen, sorry.

Ich verwende zwar mySql nicht, habe insofern keine Erfahrung, ob es da spezielle Probleme mit Distinct gibt. Aber richtig vorstellen kann ich es mir nicht, sofern die Grundregeln beachtet sind:

- Alle drei Tabellen mit einspaltigem Primärschlüssel (Integer), auch die Verknüpfungstabelle B.
- Die Fremdschlüsselspalten in B sollten indiziert sein.

Der Join sieht zwar insofern komisch aus, weil ich das konsistent schreibe:

aber ein Optimierer müßte damit auch klarkommen.

Zur Not könnte man natürlich, falls die mySql-Version Unterabfragen unterstützt, auch das nutzen:

Aber eigentlich sollten beide Varianten gleich schnell sein.

@jAuer: Leider bringt dein Tipp nichts

SQL-Abfrage:

Gibt aus:

Was ich gerne hätte:

SQL-Aufbau:

Aber es ist völlig logisch, daß Du bei einer m:n - Beziehung im Zweifelsfall mehrere Ergebnisse bzw. Ergebniswiederholungen erhälst. Das ist einfach eine Folge der Datenstruktur.

Sprich: Entweder klappt das mit den Unterabfragen (nicht bei älteren mySql) oder Du mußt Distinct nutzen und mit der Performance leben.

Abgesehen davon hast Du in der entscheidenden Tabelle B keinen Primärschlüssel. Das braucht dann natürlich lange.

mach ein group auf die felder, die zurückgegeben werden, also:
group by id,SpalteA,SpalteB

Das ist mal schick, mit den Creates und Inserts kann man doch fröhlich ausprobieren ;-)

Mir ist noch nicht ganz klar was Du eigentlich willst. Weil wenn Du nur die ID und noch zwei Felder aus TabelleA willst, dann brauchst Du überhaupt keinen Join zum B und zum C. Ohne diesen Join fallen dann auch alle Duplikate weg.

Wenn Du aber auch Daten aus TabelleC willst, dann musst Du nen Join machen. Und weil die Relation A zu C eine m:n-Relation ist, kriegst Du auch Duplikate entweder beim A oder beim C (resp. von beidem, je nach vorhandenen Daten). Das lässt sich nicht verhindern, ausser Du holst zwei separate Resultsets und stellst die dann in der Seite entsprechend dar.

Griessli
Irene

ich habe es so verstanden, dass er Duplikate raus haben will.
Group müsste da funktionieren, und bessere Performance haben als Distinct.

Aus meiner Sicht nützt ein Group da auch nichts. Die Felder, deren Werte man sehen will, müssen im "group by" sein, womit wieder Duplikate drin sind. Bei nem Group müssen alle Felder, die nicht Teil des "group by" sind, irgendwie aggregiert werden (Summe, Mittelwert, Grösstes oder Kleinstes, irgendwas halt), und das macht im Normalfall nur bei Zahlenwerten Sinn. Mit

hab ich wieder Duplikate drin. Allerdings benutze ich nicht MySQL, aber ich nehme mal an, dass MySQL die SQL-Standards genauso anwendet wie alle anderen Datenbanken.

Griessli
Irene

es sind ja alle Felder im Group By - es werden keine Felder aggregiert

er will ja nur id, spalteA, spalteB im resultset.

in seiner Abfrage am Anfang des Threads fehlt nur ein Group:



also:

Wenn man ins Select noch ein count(*) hinzufügt, zählt es sogar die Duplikate.

Vielen Dank an alle! Nun geht es um einiges schneller!