SQL: Left Join 30-fach langsamer wie where-Bedingung. Ist das normal?

[juergen]

Hallo alzaimar,

danke, nun weiß ich Bescheid.
Mir war nichtb bewußt dass die Join-Verknüpfung pro Adressdatensatz ALLE Datensätze der Kontaktpersonen durchrattert (in meinem Fall ca. 5000 x 9000 = 45 Mio).
Müsste das bei der where -Bedingung nicht auch so sein (die n*n-Durchläufe)? Denn diese Abfrage ist ja sehr schnell.
Ich weiß mir fehlen Grundlagen, aber manchmal ist man gezwungen einfach zu handeln...

[generic]

Zitat von juergen:

Sowas wie Optimizer oder SQL Ausführungspläne kenne ich für Pervasive nicht.

http://cs.pervasive.com/files/folder.../entry680.aspx

SQL query plan viewer

[juergen]

Hallo generic,
sieht interessant aus! Danke. Seit Pervasive 10 ist dieses Tool inPervasive integriert.

[jobo]

Zitat:

Müsste das bei der where -Bedingung nicht auch so sein (die n*n-Durchläufe)?

Diese Frage ist nicht unberechtigt. Aber Du brauchst im Zweifel nur den Ausführungsplan einzusehen.
Wenn er Dir nicht gefällt, musst Du Dich damit auseinandersetzen, wie Du den Optimizer auf die richtige Spur bringst. Das ist bei jedem DB Produkt unterschiedlich und natürlich bei jeder Abfrage. Und leider erscheint es (mir) nicht immer logisch, was der Optimizer plant.

Zitat von juergen:

Hallo zusammen,
--
- es gibt nur in der Tabelle Kontaktpersonen einen Index auf die Rec-ID der Tabelle AdressStamm.
..
- muss es denn in der Tabelle AdressStamm auch noch einen Index auf die Rec-ID der Tabelle Kontaktpersonen geben?

Das klingt etwas schräg.
Ein Index bezieht sich auf eine oder mehrere Spalten einer Tabelle.
Deine Beschreibung klingt etwas nach Foreign Key, der eine logische Beziehung zwischen 2 Tabellen definiert.

Idr hat man in den meisten Fällen einen Foreign Key, dessen Felder mit jeweils einem Index versehen sind.