nicht angemeldet
Moin nochmal!
Super vielen Dank für Deine ausführliche Antwort. Ich benutze Oracle. Aber ich denke mit Deiner Lösung werd ich es dann da auch hinbekommen.
Oracle - auch gut. Es wurde schon Access vermutet, und das wäre dann doch ein kleiner Unterschied. ;)
CREATE TABLE g10_ebene_temp AS
SELECT distinct ebene, thema FROM g10_ebene, g10_themen
WHERE onr=#FORM.gebaeude#
CREATE TABLE g10_ebene_thema_temp AS
SELECT distinct ebene, id FROM g10_themen, g10_ebene_thema
WHERE onr=#FORM.gebaeude#
AND thema=id
Mit dem Equi-Join erzeugst du erstmal eine Riesentabelle. Jeder Eintrag aus Tabelle 1 wird mit jedem Eintrag aus Tabelle 2 verknüpft, so daß am Ende (Zeilen Tabelle 1) x (Zeilen Tabelle 2) Zeilen entstehen. Von allen JOINs ist dies der denkbar schlechteste, wenn du nicht wirklich alle Zeilen kreuzweise mit allen anderen Zeilen verknüpft haben möchtest. Es gibt in der Regel bessere Methoden.
Ich nehm ja nicht die ganze Tabelle, sondern nur die Ebenen von dem gewählten Gebäude (von über 30 Gebäuden). Bei 8 Ebenen und 16 Themen sind es dann 128 Zeilen und so viele Zeilen soll das Ergebnis am Ende ja auch haben (alle Themen für jede Ebene).
Ich habe da irgendwie meine Zweifel. Frage: Wieviele Zeilen sind in Tabelle g10_ebene enthalten? Wieviele Zeilen sind in Tabelle g10_themen enthalten? Diese beiden Zahlen multipliziert ergibt die temporäre Tabellengröße, bevor die Selektion mit WHERE onr=#FORM.gebaeude# loslegt. Danach ist die Tabelle kleiner oder maximal genauso groß, aber dazwischen ist sie vermutlich recht groß. Kann natürlich sein, daß Oracle sowas optimiert (kann auch bei anderen DBMS sein), aber kann eben auch nicht sein.
Bei tausend Zeilen Endgröße (also knapp 30 Zeilen in jeder der beiden Tabellen) ist die ungünstige Datenbankabfrage ganz sicher nicht zu merken. Wenn aber jede Tabelle tausend Zeilen enthält, wird das Zwischenprodukt schon eine Million Zeilen groß, und so weiter. Da ist es doch besser, man achtet gleich auf eine "gute" Abfrage. :)
- Sven Rautenberg