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
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
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.
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
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 …
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.
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*
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.
