Joins verknüpfen

[Kerstin]

Hallo,

gibt es die Möglichkeit verschiedene Joins in einer DB-Abfrage zu verknüpfen?
Ich möchte einen Outer Join nicht auf zwei Tabellen, sondern auf zwei durch Equi-Joins verknüpfte Tabellen anwenden.
Geht das oder muss ich mir zuerst temporäre Tabellen anlegen, die ich dann durch den outer join verknüpfen kann?

viele Grüsse
Kertin

[Philipp Hasenfratz]

Halihallo

gibt es die Möglichkeit verschiedene Joins in einer DB-Abfrage zu verknüpfen?

Allgemein gesagt: Ja, das macht man ja eigentlich immer, wenn man mehrere Tabellen in einen Query packt.

Ich möchte einen Outer Join nicht auf zwei Tabellen, sondern auf zwei durch Equi-Joins verknüpfte Tabellen anwenden.
Geht das oder muss ich mir zuerst temporäre Tabellen anlegen, die ich dann durch den outer join verknüpfen kann?

Wenn ich dein Vorhaben richtig verstanden habe, kommst du nicht um eine temporäre Tabelle herum.
Aber zum Überprüfen meiner Aussage wären einige Beispieldaten und den entsprechenden Query nötig (kann ja sein, dass ich dich missverstanden habe).

Viele Grüsse

Philipp

[Kerstin]

Halihallo

gibt es die Möglichkeit verschiedene Joins in einer DB-Abfrage zu verknüpfen?

Allgemein gesagt: Ja, das macht man ja eigentlich immer, wenn man mehrere Tabellen in einen Query packt.

Ich möchte einen Outer Join nicht auf zwei Tabellen, sondern auf zwei durch Equi-Joins verknüpfte Tabellen anwenden.
Geht das oder muss ich mir zuerst temporäre Tabellen anlegen, die ich dann durch den outer join verknüpfen kann?

Wenn ich dein Vorhaben richtig verstanden habe, kommst du nicht um eine temporäre Tabelle herum.
Aber zum Überprüfen meiner Aussage wären einige Beispieldaten und den entsprechenden Query nötig (kann ja sein, dass ich dich missverstanden habe).

Viele Grüsse

Philipp

Hallo Philipp,

danke für Deine Antwort. Ich hab es jetzt mal mit temporären Tabellen versucht und jetzt weiss ich zumindest, dass es überhaupt funktioniert:-)

Ich möchte für verschiedene Gebäudeebenen Themen festlegen. Das heisst, wenn man ein Gebäude wählt, sollen für jede Ebene alle Themen angezeigt werden. Die Themen die der Ebene bereits zugewiesen sind, sollen durch eine Checkbox markiert sein, so dass diese auch wieder abgewählt und neue hinzugewählt werden können. Dazu hab ich 3 Tabellen: eine mit allen Ebenen, eine mit allen Themen und eine Tabelle, in der den Ebenen Themen zugewiesen sind.
Als Ergebnis möchte ich dann also ne Liste haben, in der alle Ebenen mit allen Themen vorkommen, also auch die Ebenen, wo es das Thema nicht gibt und das Feld dann eben leer ist.
Ich hoff mal, das ist jetzt nicht zu konfus, hier sind mal die querys, wie es mit temporären Tabellen geklappt hat.

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

select distinct g10_ebene_temp.ebene, g10_ebene_temp.id, g10_ebene_thema_temp.id from g10_ebene_temp, g10_ebene_thema_temp where g10_ebene_temp.id=g10_ebene_thema_temp.id(+) order by g10_ebene_temp.ebene;

viele Grüsse Kerstin

[Sven Rautenberg]

Moin!

Ich hoff mal, das ist jetzt nicht zu konfus, hier sind mal die querys, wie es mit temporären Tabellen geklappt hat.

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

Um Gottes Willen! Das ist ja der Performance-Killer hoch 10!

Warum?

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.

Mit SELECT DISTINCT sortierst du dann alle Zeilen aus, die doppelte Einträge in den Spalten "ebene" und "thema" haben. SELECT DISTINCT isb ebenfalls langsam, da sehr viele Vergleiche ausgeführt werden müssen, um doppelte Einträge zu eliminieren.

Es gibt bessere Methoden, dein Ziel zu erreichen. Beispielsweise gibts den LEFT OUTER JOIN. Aber mal der Reihe nach:

Du hast 3 Tabellen für Ebenen, Themen und zugeordnet Ebene<->Thema

Du willst für eine einzelne Ebene wissen:
Welche Themen sind der Ebene zugeordnet, und welche Themen gibts insgesamt, so daß man ein Checkboxformular damit befüllen kann.

Als Ergebnis stellst du dir also folgende Tabelle vor:

Ebene Thema Themaname
  1     1    Thema1
  1     2    Thema2
  -     3    Thema3
  1     4    Thema4

Drei Themen sind Ebene 1 zugeordnet (ich abstrahiere mal), und es gibt insgesamt 4 Themen.

Die Daten kommen aus folgenden Einzeltabellen:
Tabelle Ebene:
EbeneID  weitere Infos
#1       Info zu Ebene 1

Tabelle Thema
ThemaID  Themaname
#1       Thema1
#2       Thema2
#3       Thema3
#4       Thema4

Tabelle Thema<->Ebene
ID EbeneID ThemaID
#1   #1     #1
#2   #1     #2
#3   #1     #4

Was willst du genau wissen? Primär: Welche Themen gibts alle? Das wird also dein SELECT.

Dann: Welches der vorhandenen Themen ist mit Ebene 1 verknüpft? Denn diese Themen sollen ja selektiert erscheinen. Das wird dein erster JOIN (welcher, ist noch zu entscheiden...).

Und als drittes: Brauchst du noch weitere Informationen zu Ebene 1, die in der Ebenen-Tabelle stehen? Das wäre dann der zweite JOIN.

Wichtig ist, daß die IDs die Verknüpfung korrekt herstellen. Als "primary auto_increment key" ist sowas immer gut und stellt die Datenintegrität sicher.

Zurück zum JOINen:

SELECT thema.themenID, thema.spalte1, thema.spalte2 FROM thema
Das sorgt dafür, daß einfach alle vorhandenen Themen selektiert werden. Easy. :)

Jetzt muß dann, wenn Ebene 1 mit dem Thema verknüpft ist, das in der Tabelle deutlich gemacht werden. Wenn Ebene 1 nicht verknüpft ist, soll die Themenzeile aber erhalten bleiben. Für sowas ist der LEFT OUTER JOIN gut, denn der macht genau das. Siehe auch http://www.little-idiot.de/mysql/mysql-118.html

SELECT t.themaID, t.Themaname, te.ebeneID, te.themaID
FROM thema AS t
LEFT OUTER JOIN themaebene AS te
ON t.themaID=te.themaID AND te.ebeneID = 1

Im Select werden alle Spalten der entstehenden Tabelle gelistet. Ich hab' der Einfachheit halber mit Alias-Namen für die Tabellen gearbeitet.

Wenn du das Ergebnis siehst, sollte das schon deinen Wünschen entgegenkommen: Alle Themen vorhanden, und die Themen der Ebene 1 haben eine Kennzeichnung.

Das ist im Prinzip schon, was du willst. Wenn noch die Daten der Ebene 1 angehängt werden, machst du einen normalen JOIN auf diese Tabelle:

SELECT t.themaID, t.Themaname, te.ebeneID, te.themaID, e.ebeneID, e.spalte1, e.spalte2
FROM thema AS t
LEFT OUTER JOIN themaebene AS te
ON t.themaID=te.themaID AND te.ebeneID = 1
JOIN ebene AS e
ON te.ebeneID = e.ebeneID
ORDER BY irgendwas
LIMIT BY irgendwas

Fertig. :) Jedenfalls theoretisch. Ich hab's in einem anderen Zusammenhang, aber mit ziemlich exakt deiner Aufgabenstellung schon mal so hingekriegt - wenn Fehler in dieser Lösung drin sind, dann liegts an Flüchtigkeitsfehlern und Kleinigkeiten, die aus Versehen reingerutscht sind, aber nicht an der grundsätzlichen Unmöglichkeit.

Folge dem Link und probiere selbst einmal ein wenig rum. Mit SQL ist sehr viel mehr möglich, als der Standardbenutzer weiß. :)

- Sven Rautenberg

[Philipp Hasenfratz]

Halihallo allerseits

SELECT t.themaID, t.Themaname, te.ebeneID, te.themaID, e.ebeneID, e.spalte1, e.spalte2
FROM thema AS t
LEFT OUTER JOIN themaebene AS te
ON t.themaID=te.themaID AND te.ebeneID = 1
JOIN ebene AS e
ON te.ebeneID = e.ebeneID
ORDER BY irgendwas
LIMIT BY irgendwas

Von dir kann man noch allerhand lernen, lieber Sven :-)

Fertig. :) Jedenfalls theoretisch. Ich hab's in einem anderen Zusammenhang, aber mit ziemlich exakt deiner Aufgabenstellung schon mal so hingekriegt - wenn Fehler in dieser Lösung drin sind, dann liegts an Flüchtigkeitsfehlern und Kleinigkeiten, die aus Versehen reingerutscht sind, aber nicht an der grundsätzlichen Unmöglichkeit.

Ja, wenn man ne gute RDBMS hat, aber am Query, den Kerstin geschrieben hat, erkenne ich den SQL - Dialekt von MS - Access... Dort wird sie mit Joins wohl etwas Probleme bekommen (glaube ich zumindest).

Folge dem Link und probiere selbst einmal ein wenig rum. Mit SQL ist sehr viel mehr möglich, als der Standardbenutzer weiß. :)

Ausser man hat Access :-)
Aber ja. SQL ist auf den ersten Blick ganz einfach (und bleibt es auch), aber was man mit dieser "Leichtigkeit" alles machen kann, ist schon sehr toll.

Viele Grüsse

Philipp

[Klaus Mock]

Hallo,

Ja, wenn man ne gute RDBMS hat, aber am Query, den Kerstin geschrieben hat, erkenne ich den SQL - Dialekt von MS - Access... Dort wird sie mit Joins wohl etwas Probleme bekommen (glaube ich zumindest).

Da glaubst Du AFAIK etwas Falsches. OUTER JOIN hat es, wenn ich mich nicht vollkomme irre, schon in Access 1.0, spätestens jedoch in Access 2.0 gegeben. Die Datenbankengine von Access kann nicht mal so wenig, zumindest was den Funktionsumfang angeht. In einigen Punkten ist sie IMHO mySQL bei weitem überlegen.

Und zu einer Frage in einem anderen Posting von Dir hier im Thread: Ja, IMHO kann man Access durchaus als RDBMS bezeichnen. Zumindest wenn man das auch bei mySQL macht.

Willst Du ein kostenfreies Datenbanksystem, das die Funktionalität der 'Großen' mitbringt (Constraints, Views, Trigger, Transaktionen, Stored Procedures ...) so solltest Du Dir einmal Interbase/Firebird ansehen http://www.ibphoenix.com. Die ist wirklich nicht schlecht. PostgreSQL ist AFAIK auch recht komplett, nur ich kenne sie nicht.

Grüße
  Klaus

[Philipp Hasenfratz]

Halihallo Klaus

Ja, wenn man ne gute RDBMS hat, aber am Query, den Kerstin geschrieben hat, erkenne ich den SQL - Dialekt von MS - Access... Dort wird sie mit Joins wohl etwas Probleme bekommen (glaube ich zumindest).

Da glaubst Du AFAIK etwas Falsches. OUTER JOIN hat es, wenn ich mich nicht vollkomme irre, schon in Access 1.0, spätestens jedoch in Access 2.0 gegeben. Die Datenbankengine von Access kann nicht mal so wenig, zumindest was den Funktionsumfang angeht. In einigen Punkten ist sie IMHO mySQL bei weitem überlegen.

Das war mir neu, danke für die Berichtigung! - Hatte mal ein kleines Projekt mit ASP / Access umzusetzen, da hatte ich immense Probleme mit dem SQL von Access, ich hatte dann fälschlicherweise angenommen, dass dies nicht unterstützt wird (naja, normalerweise suche ich ja den Fehler erst bei mir selber, aber bei M$ habe ich da mal ne ausnahme gemacht :-) ).

Und zu einer Frage in einem anderen Posting von Dir hier im Thread: Ja, IMHO kann man Access durchaus als RDBMS bezeichnen. Zumindest wenn man das auch bei mySQL macht.

ACK. 'tschuldige, dass ich so über MS Access hergezogen bin :-)

Willst Du ein kostenfreies Datenbanksystem, das die Funktionalität der 'Großen' mitbringt (Constraints, Views, Trigger, Transaktionen, Stored Procedures ...) so solltest Du Dir einmal Interbase/Firebird ansehen http://www.ibphoenix.com. Die ist wirklich nicht schlecht. PostgreSQL ist AFAIK auch recht komplett, nur ich kenne sie nicht.

Interbase hab ich schon getestet und bin auch ganz stark von überzogen. Über PostgreSQL hab ich auch schon einiges gutes gehört, aber kennen tu ich's auch nicht. Hinzu kommt, dass ich eigentlich völliger MySQL Anhänger bin und woimmer möglich auch diese DB benutze; der Leistungsumfang ist zwar ziemlich schlecht, aber mir hat er bisher immer gereicht und von der Performance her ist mysql ja sehr gut (um NULL Euro).

Viele Grüsse

Philipp

[Kerstin]

Hallo Sven,

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.

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

Um Gottes Willen! Das ist ja der Performance-Killer hoch 10!

Das hab ich auch befürchtet, deshalb hab ich ja mal hier nachgefragt ;-)

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).

Mit SELECT DISTINCT sortierst du dann alle Zeilen aus, die doppelte Einträge in den Spalten "ebene" und "thema" haben. SELECT DISTINCT isb ebenfalls langsam, da sehr viele Vergleiche ausgeführt werden müssen, um doppelte Einträge zu eliminieren.

Es gibt bessere Methoden, dein Ziel zu erreichen. Beispielsweise gibts den LEFT OUTER JOIN. Aber mal der Reihe nach:

Du hast 3 Tabellen für Ebenen, Themen und zugeordnet Ebene<->Thema

Du willst für eine einzelne Ebene wissen:
Welche Themen sind der Ebene zugeordnet, und welche Themen gibts insgesamt, so daß man ein Checkboxformular damit befüllen kann.

Als Ergebnis stellst du dir also folgende Tabelle vor:

Ebene Thema Themaname
  1     1    Thema1
  1     2    Thema2
  -     3    Thema3
  1     4    Thema4

Drei Themen sind Ebene 1 zugeordnet (ich abstrahiere mal), und es gibt insgesamt 4 Themen.

Die Daten kommen aus folgenden Einzeltabellen:
Tabelle Ebene:
EbeneID  weitere Infos
#1       Info zu Ebene 1

Tabelle Thema
ThemaID  Themaname
#1       Thema1
#2       Thema2
#3       Thema3
#4       Thema4

Tabelle Thema<->Ebene
ID EbeneID ThemaID
#1   #1     #1
#2   #1     #2
#3   #1     #4

Was willst du genau wissen? Primär: Welche Themen gibts alle? Das wird also dein SELECT.

Dann: Welches der vorhandenen Themen ist mit Ebene 1 verknüpft? Denn diese Themen sollen ja selektiert erscheinen. Das wird dein erster JOIN (welcher, ist noch zu entscheiden...).

Und als drittes: Brauchst du noch weitere Informationen zu Ebene 1, die in der Ebenen-Tabelle stehen? Das wäre dann der zweite JOIN.

Wichtig ist, daß die IDs die Verknüpfung korrekt herstellen. Als "primary auto_increment key" ist sowas immer gut und stellt die Datenintegrität sicher.

Zurück zum JOINen:

SELECT thema.themenID, thema.spalte1, thema.spalte2 FROM thema
Das sorgt dafür, daß einfach alle vorhandenen Themen selektiert werden. Easy. :)

Jetzt muß dann, wenn Ebene 1 mit dem Thema verknüpft ist, das in der Tabelle deutlich gemacht werden. Wenn Ebene 1 nicht verknüpft ist, soll die Themenzeile aber erhalten bleiben. Für sowas ist der LEFT OUTER JOIN gut, denn der macht genau das. Siehe auch http://www.little-idiot.de/mysql/mysql-118.html

SELECT t.themaID, t.Themaname, te.ebeneID, te.themaID
FROM thema AS t
LEFT OUTER JOIN themaebene AS te
ON t.themaID=te.themaID AND te.ebeneID = 1

Im Select werden alle Spalten der entstehenden Tabelle gelistet. Ich hab' der Einfachheit halber mit Alias-Namen für die Tabellen gearbeitet.

Wenn du das Ergebnis siehst, sollte das schon deinen Wünschen entgegenkommen: Alle Themen vorhanden, und die Themen der Ebene 1 haben eine Kennzeichnung.

Das ist im Prinzip schon, was du willst. Wenn noch die Daten der Ebene 1 angehängt werden, machst du einen normalen JOIN auf diese Tabelle:

SELECT t.themaID, t.Themaname, te.ebeneID, te.themaID, e.ebeneID, e.spalte1, e.spalte2
FROM thema AS t
LEFT OUTER JOIN themaebene AS te
ON t.themaID=te.themaID AND te.ebeneID = 1
JOIN ebene AS e
ON te.ebeneID = e.ebeneID
ORDER BY irgendwas
LIMIT BY irgendwas

Fertig. :) Jedenfalls theoretisch. Ich hab's in einem anderen Zusammenhang, aber mit ziemlich exakt deiner Aufgabenstellung schon mal so hingekriegt - wenn Fehler in dieser Lösung drin sind, dann liegts an Flüchtigkeitsfehlern und Kleinigkeiten, die aus Versehen reingerutscht sind, aber nicht an der grundsätzlichen Unmöglichkeit.

Folge dem Link und probiere selbst einmal ein wenig rum. Mit SQL ist sehr viel mehr möglich, als der Standardbenutzer weiß. :)

Jetzt weiss ich doch, dass es funktioniert. Da war ich mir nämlich nicht sicher. Hatte schon eine Weile rumprobiert, aber ohne Erfolg und da hab ichs dann erstmal so gemacht, wie es sicher ging ;-)
Danke, werd dann mal ein bisschen rumprobieren :-)

Kerstin

[Sven Rautenberg]

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

[Michael Schröpl]

Hi Sven,

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.

wenn Oracle über "onr" einen (hinreichend stark projezierenden) Index findet, wird es wahrscheinlich (rule-based oder cost-based optimizer?) den JOIN so umschreiben, daß die innere Schleife über diesen Index läuft.
Dann käme im Wesentlichen das heraus, was Kerstin sich unter dem Ablauf dieses JOIN vorstellt, denke ich.

Aber sich den execution plan dieser statements mal ausgeben zu lassen, ist sicherlich keine schlechte Idee ...

Viele Grüße
      Michael

[Kerstin]

Hallo

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.

wenn Oracle über "onr" einen (hinreichend stark projezierenden) Index findet, wird es wahrscheinlich (rule-based oder cost-based optimizer?) den JOIN so umschreiben, daß die innere Schleife über diesen Index läuft.
Dann käme im Wesentlichen das heraus, was Kerstin sich unter dem Ablauf dieses JOIN vorstellt, denke ich.

Aber sich den execution plan dieser statements mal ausgeben zu lassen, ist sicherlich keine schlechte Idee ...

Wie geht sowas denn? Hab mir ehrlich gesagt noch nie Gedanken darüber gemacht, was zuerst ausgeführt wird. An der Performance selber hab ich nix gemerkt, es sind insgesamt ungefähr 300*16 Zeilen, und es ist auch "nur" fürs Intranet, da wär es nicht ganz so schlimm, aber ich möcht ja auch was dazulernen und vielleicht hab ich mal ein ähnliches Problem, wo es dann stärker drauf ankommt.

Gruss Kerstin

[Michael Schröpl]

Hi Kerstin,

gibt es die Möglichkeit verschiedene Joins in einer DB-Abfrage
zu verknüpfen?

das SQL-Sprachelement Deiner Wahl nennt sich m. E. "view" - fragt sich
bloß, ob Dein RDBMS (welches Du nicht genannt hast) das auch unterstützt.

Viele Grüße
      Michael

[Philipp Hasenfratz]

Halihallo

das SQL-Sprachelement Deiner Wahl nennt sich m. E. "view" - fragt sich
bloß, ob Dein RDBMS (welches Du nicht genannt hast) das auch unterstützt.

Ja, da hast du recht. Damit kann man einiges machen...
Nur, dass leider MySQL das nicht unterstützt (mein geliebtes MySQL...). Mit Access (darf man das überhaupt RDBMS nennen?) hat man sowieso schlechte Karten.
Um eine DB mit Views zu kriegen muss man "meistens" etwas mehr Geld hinlegen.

Viele Grüsse

Philipp

[Kerstin]

Hallo Michael

gibt es die Möglichkeit verschiedene Joins in einer DB-Abfrage
zu verknüpfen?

das SQL-Sprachelement Deiner Wahl nennt sich m. E. "view" - fragt sich
bloß, ob Dein RDBMS (welches Du nicht genannt hast) das auch unterstützt.

das wär kein Problem, ich benutz Oracle. Werd ich dann auch mal ausprobieren.
Nachdem ich in der letzten Zeit eher mit MySQL gearbeitet hab, hab ich wohl vergessen, dass es sowas gibt ;-)

Danke, Kerstin