Joins Vor- und Nachteil

Schönen juten Tag :smile:

Ich sitze hier grade und lerne für eine Datenbankklausur mit SQL Inhalt. Leider ging unser Prof. nicht auf die Vor- und Nachteile seiner vorgestellten Joins ein. Möglichkeit, richtig zu fragen, war damals auch nicht gegeben.

Richtig was im Internet hab ich jetzt auch nicht gefunden, was vergleiche aufstellt :confused:

Welche Vorteile seht ihr aus der Erfahrung oder vom hören und sagen. Ich denke, das Vor- und Nachteile erst wirklich erkennbar sind, wenn man mit richtigen Datenbanken arbeitet und nicht mit 4 Tabellen, die jeweils 3-4 Tupel haben, wie bei uns.

Es geht um die klassischen Verbünde, z.B.:
select blabla
from Kunde, Auftrag
where Kunde.KundenNr = Auftrag.KundenNr
–> Macht einen sehr statischen Eindruck

Natürlicher Verbund, z.B.:
select blabla
from Kunde natural join Auftrag
where blabla
–> Macht einen dynamischen Eindruck

Spaltenname-Verbund:
select blabla
from Kunde join Auftrag using KundenNr
where blabla
–> Auch lustig, kommt zwar im Skript vor, aber in SQL Anywhere kann man mit join und using nicht arbeiten -.-

Bedingter Verbund:
select blabla
from Kunde join Auftrag on Auftrag.KundenNr = KundenNr
where blabla

Ich weiss auch, das man noch in den Bereich Left outer join, Right outer join gehen kann, aber das hat er nicht ins Skript gepackt o_O

Danke für ein kurzes Statement :smile:

Viele Grüße

Moin, welcome,

mit Deinen Kategorien statisch und dynamisch fange ich nichts an - was machst Du damit?

1 und 4 sind unterschiedliche Schreibweisen für den gleichen Zugriff, 2 und 3 kenne ich nicht, die scheinen DBMS-abhängig zu gelten (oder eben nicht).

Joins haben aus meiner Sicht keine Vor- und Nachteile, die Schreibweisen sind Geschmackssache. Die Anweisung heißt doch lediglich: Bilde das Kreuzprodukt aus 2 (oder mehr) Tabellen und gib die Regel an, nach der aus dem Kreuzprodukt ausgewählt wird. Den Rest macht eh der Optimizer.

Gruß Ralf

Ergänzung

Bilde das Kreuzprodukt aus 2 (oder mehr) Tabellen
und gib die Regel an, nach der aus dem Kreuzprodukt ausgewählt
wird.

und bei Left-, Right-, Outer-Join ist ein Teil dieser Regel bereits vorgegeben, somit liest sich das Ganze leichter.

Gruß Ralf

Hi,

Da kann ich mich Ralf nur anschließen…
Vor- und nachteile gibt es da nicht. Je nachdem wie eine DB aufgebaut ist, kann das eine oder andere schneller sein. Das in Bezug auf die enthaltene Datenmenge ist immer anders.

Was mich jedoch zu einer Bemerkung reizt:

Die Profs sind in der Tat diejeniegen die das ERM rauf und runterbeten können. Keine noch so komplexe Frage, die nicht mir der 121. Normalform beantwortet werden kann.
Setz die Mehrheit von denen mal an eine Datenbank aus dem Leben.
Genau.

Aber genau das ist es. Theorie kennen, soweit man sie braucht. Alles andere sind Erfahrungswerte oder Philosophie. Sorry :smile:

Gruß
Proteus

Hi!

2 und 3 kenne ich nicht

Jössas!

Natural Join: Der vergleicht die Tabellen auf selben Spaltennamen und joint diese von selber zusammen.
Meine persönliche Einschätzung: GEFÄHRLICH! (und nicht unbedingt brauchbar)
Beim „USING“ gibt man in Klammer den Spaltennamen an, der in beiden Tabellen ebenfalls gleich sein muß.
Meine persönliche Einschätzung: GEFÄHRLICH! (und nicht unbedingt brauchbar)

(also hast Du zumindest nix versäumt)

Schreibweisen sind Geschmackssache

Vor 5 Jahren mußte ich nach 15 Jahren Oracle für den OCP eine SQL-Prüfung machen und ich MUSSTE das ganze Join-Dingensen theoretisch lernen; das Einzige brauchbare war der FULL OUTER JOIN, aber auch nur weil ich in Oracle kein (+) auf beide Seiten der Where-Bedingung geben kann …

Grüße,
Tomh

[ot] Wozu ERM?
Moin, Proteus,

Die Profs sind in der Tat diejeniegen die das ERM rauf und
runterbeten können. Keine noch so komplexe Frage, die nicht
mir der 121. Normalform beantwortet werden kann.

ich bin zwar kein Prof, sondern musste mein Brot immer mit ehrlicher Arbeit verdienen. Aaaaber: Ohne ERM keine Datenbank! Was mir meine sauberen Entwürfe schon alles erspart habe, geht auf keine Kuhhaut. Und weiter als bis zur 3. NF war ich noch nicht im Keller, was darüber hinaus geht, ist wahrlich akademischer Quark.

Gruß Ralf

Hallo Ralf,
da stimme ich dir voll und ganz zu !
Gruß
Proteus

In der Theorie ists egal, über wie viele Tabellen gejoint wird.
In der Praxis aber nicht - hier muss optimiert werden, wenn bestimmte Informationen häufiger (und schneller) benötigt werden.
Daher sch*** auf die Normalform *ggg*

Gruß Gerald

Moin, Gerald,

In der Theorie ists egal, über wie viele Tabellen gejoint
wird.
In der Praxis aber nicht - hier muss optimiert werden, wenn
bestimmte Informationen häufiger (und schneller) benötigt
werden.
Daher sch*** auf die Normalform *ggg*

was Du hier sch*** nennst, heißt bei Entwicklern mit Verstand Denormalisierung. Um das machen zu können, muss aber erstmal ein normalisiertes Modell vorliegen. Oder nach anders gesagt: Da zeigt sich, warum es ein logisches und ein physisches Modell gibt.

Gut Holz!
Gruß Ralf