Einstiegsartikel: JOINs

[Rouven]

Hallo,

vor einigen Tagen kam die Anregung, man könne doch mal einen Einsteigerartikel zum Thema Joins zusammenstellen, damit man Anfängern leicht die einzelnen Join-Arten näher bringen kann. Wie bereits von mir angekündigt habe ich an meinem ersten Entwurf noch einige Korrekturen vorgenommen und stelle ihn nun zur Debatte.
Vinzenz Mai und ich hatten uns schonmal abgestimmt, dass er den Artikel für Fortgeschrittene macht, der Link fehlt im Moment noch.

Also, ich freu mich über Feedback, den Entwurf gibts hier: http://tsdnet.ts.funpic.de/joins_leicht_gemacht.htm

MfG
Rouven

[Daniela Koller]

Hi Rouven

Nach dem groben Durchlesen sind mir einige Dinge aufgefallen:

Fachwörter:
 - Einführung des Begriffs Relation ohne Erklärung
 - Begriffsverwirrung Datenbank <-> Tabellen, siehe nächster
   Satz:
    All dies ist hinfällig, wenn die Tabellenstruktur nur
    leicht angepasst wird.
   Nicht die Tabellenstruktur wird angepasst, sondern die
   Datenbankstruktur.

Sonstiges:
 - Der Hinweis: Diese Schreibweise ist stark abhängig vom
    eingesetzten Join und kann in aller Regel nur beim  INNER
    JOIN verwendet werden.
   nervt beim wiederholt werden.

Fehlende Themen:
 - Natural Joins
 - Using

Vielleicht finden die fehlenden Themen auch im weiterführenden Artikel Platz.

Was ich generell schöner fände, wäre ein einzelner Artikel zu dem Thema, da sonst die Leser immer genau schauen müssen, in welchem Teil nun ihr Problem besprochen wird. Vielleicht könnt ihr die beiden Teile auch zu einem Artikel zusammenfügen.

Gruss Daniela

[Vinzenz Mai]

Hallo

Was ich generell schöner fände, wäre ein einzelner Artikel zu dem Thema, da sonst die Leser immer genau schauen müssen, in welchem Teil nun ihr Problem besprochen wird. Vielleicht könnt ihr die beiden Teile auch zu einem Artikel zusammenfügen.

hier der Link zu meinen zweiten Entwurf, den ich damit ebenfalls zur Diskussion stelle.

Ob ein oder zwei Artikel sinnvoll sind, warum sollte man sich nicht hier in diesem Kreis damit auseinandersetzen? Die Intention vor allem für den Grundlagenartikel war eher unter "praktischer Nutzen" für Datenbankeinsteiger als "datenbanktheoretisch exakt" angesiedelt.

Nach dem groben Durchlesen sind mir einige Dinge aufgefallen:

Fachwörter:

• Einführung des Begriffs Relation ohne Erklärung

Fachwörter stellen sicher immer ein Problem dar, da oft eines zum anderen führt und man so als Autor eventuell das eigentliche Ziel aus den Augen verliert.

Fehlende Themen:

• Natural Joins

Vielleicht auf dem Weg von der Normalisierung zurück die Zwischenschritte Equijoin und Natürlicher Join (der Theorie) vorstellen. In den meisten Fällen wird man eher eine Projektion verwenden, die noch ein paar Spalten mehr ausblendet als nur die doppelte :-)

• Using

hatte ich in meinem ersten Versuch am Ende des Artikels erwähnt. Ich weiß nicht, ob und wenn ja in welchem Standard USING eingeführt wurde, und wie die Unterstützung durch die verschiedenen DBMS aussieht.

Vielleicht in einem Abschnitt "propietäre Syntax"? Mit den proprietären alten Schreibweisen für LEFT/RIGHT JOIN?

Vielleicht finden die fehlenden Themen auch im weiterführenden Artikel Platz.

Freundliche Grüße

Vinzenz

[Rouven]

Hallöchen!

Ich geh mal gerade die Punkte ab:

• Einführung des Begriffs Relation ohne Erklärung

Das ist richtig, die Frage ist, in wie weit das Sinn macht das hier auszuführen. Nach meinem Verständnis liest diesen Artikel der durchschnittliche "ich hab da mal ein XAMPP installiert und hätte da mal gerne ein Problem"-Nutzer. Ich bezweifele, dass es ihn interessiert wie mathematisch eine Relation definiert ist. Anders herum, sollte doch mal jemand nachlesen der Interesse an dem Thema hat, so weiß er, wo er nachschlagen kann.
Wenn, dann tendiere ich eher dazu, den Begriff rauszunehmen und den Hintergrund ganz außen vor zu lassen.

• Begriffsverwirrung Datenbank <-> Tabellen, siehe nächster
     Satz:
      All dies ist hinfällig, wenn die Tabellenstruktur nur
      leicht angepasst wird.
     Nicht die Tabellenstruktur wird angepasst, sondern die
     Datenbankstruktur.

OK, Kenntnisnahme.

Sonstiges:

• Der Hinweis: Diese Schreibweise ist stark abhängig vom
      eingesetzten Join und kann in aller Regel nur beim  INNER
      JOIN verwendet werden.
     nervt beim wiederholt werden.

Seh ich ein, nervt mich auch, steht vor dem Hintergrund: Liest man den Artikel von vorne bis hinten oder schaut man ein Stichwort nach.

Fehlende Themen:

• Natural Joins

Das benutzt jemand? Das braucht jemand?

• Using

*Mist* das muss ich nachschlagen.

MfG
Rouven

[Vinzenz Mai]

Hallo Rouven,

• Using
  *Mist* das muss ich nachschlagen.

kennt DB2 "USING"?

Freundliche Grüße

Vinzenz

[Daniela Koller]

Hi Rouven

Wenn, dann tendiere ich eher dazu, den Begriff rauszunehmen und den Hintergrund ganz außen vor zu lassen.

Ja, in dem Zusammenhang würde ich auch eher zum Rausnehmen tendieren.

JOIN verwendet werden.
   nervt beim wiederholt werden.
Seh ich ein, nervt mich auch, steht vor dem Hintergrund: Liest man den Artikel von vorne bis hinten oder schaut man ein Stichwort nach.

Ich denke, wer nach Stichworten guckt, hat schon Ahnung und es fehlt ihm vielleicht nur die Syntax.

Fehlende Themen:

• Natural Joins
  Das benutzt jemand? Das braucht jemand?

Du solltest zumindest auf die Probleme hinweisen. Es werden nicht etwa wie erwartet die entsprechend per Fremdschlüssel/Primärschlüssel verbundenen Spalten benutzt, nein, zumindest Postgres geht auf Namensgleichheit.

• Using
  *Mist* das muss ich nachschlagen.

Eigentlich nicht:
JOIN ... ON (a.id = b.id) <-> JOIN ... USING(id), sprich, dann nützlich, wenn du bestimmte gleichnamige Spalten hast. und über die verbinden willst.

Gruss Daniela

P.S: Wenn du ihn eingereicht hast und evtl. keine Reaktion kriegst, schreib mich bitte direkt an, Datenbankartikel krieg üblicherweise ich, und ich übersehs ab und zu wenn was neues kommt.

[Rouven]

Hi Daniela,

P.S: Wenn du ihn eingereicht hast und evtl. keine Reaktion kriegst, schreib mich bitte direkt an, Datenbankartikel krieg üblicherweise ich, und ich übersehs ab und zu wenn was neues kommt.

Wo wir gerade so ganz zufällig beim Thema sind: ich hab mehr aus heiterem Himmel und einer Sonntags-Nachmittags-Lust letzte Woche mit dem Schreiben angefangen, wie funktioniert das mit dem Einreichen?

MfG
Rouven

[Daniela Koller]

Hi Rouven

Wo wir gerade so ganz zufällig beim Thema sind: ich hab mehr aus heiterem Himmel und einer Sonntags-Nachmittags-Lust letzte Woche mit dem Schreiben angefangen, wie funktioniert das mit dem Einreichen?

Gute Frage, auf der Seite dazu http://aktuell.de.selfhtml.org/artikel/beitrag.htm steht eigentlich noch Stefans Mailadresse, ich denke es ist aber geschickter, wenn du ihn einfach zusammenpackst und komprimierst und mir oder einem anderen Dev schickst. Dann kommt er in ein Reviewverzeichnis, und wird Korrekturgelesen, kleinere Änderungen wie Tippfehler oder kleine Layoutfehler werden direkt von uns korrigiert, grössere Probleme oder Wünsche unsererseits werden per Mail besprochen.

Gruss Daniela

[Vinzenz Mai]

Hallo Rouven,

vor einigen Tagen kam die Anregung, man könne doch mal einen Einsteigerartikel zum Thema Joins zusammenstellen, damit man Anfängern leicht die einzelnen Join-Arten näher bringen kann. Wie bereits von mir angekündigt habe ich an meinem ersten Entwurf noch einige Korrekturen vorgenommen und stelle ihn nun zur Debatte.

"einige Korrekturen", Du untertreibst :-)

Vinzenz Mai und ich hatten uns schonmal abgestimmt, dass er den Artikel für Fortgeschrittene macht, der Link fehlt im Moment noch.

Leicht zu ändern: Da gibt es den zweiter Entwurf.

Also, ich freu mich über Feedback, den Entwurf gibts hier: http://tsdnet.ts.funpic.de/joins_leicht_gemacht.htm

Mir gefällt er nach der Überarbeitung noch besser, ich bleibe bei meiner Bewertung. Ich habe bei meinem allerersten Versuch selbst gemerkt, wie schwierig der Spagat zwischen einem Einsteigerartikel und exakter Anwendung von Begriffen aus der Datenbanktheorie ist, von Vollständigkeit mal ganz zu schweigen (die meiner Meinung nach hier auch nichts verloren hat).

Freundliche Grüße

Vinzenz

[Christoph Zurnieden]

Hi,

ich wuerde ja normalerweise gar nichts sagen, aber das das hier unter dem SELFHTML-Label laufen soll:

Fuer tabellarische Daten hat das W3C das Element 'table' mitsamt Anverwandschaft bestimmt und kein "PRE" mit einer in ASCII gemalten Tabelle drin.

so short

Christoph Zurnieden

[Vinzenz Mai]

Hallo Christoph,

Fuer tabellarische Daten hat das W3C das Element 'table' mitsamt Anverwandschaft bestimmt und kein "PRE" mit einer in ASCII gemalten Tabelle drin.

grundsätzlich gebe ich Dir ja recht. Aber ich habe mich

- nur an die bestehenden Beispiele gehalten
  - und war andererseits faul (so war nur copy & paste erforderlich)

Freundliche Grüße

Vinzenz

[Christoph Zurnieden]

Hi,

Fuer tabellarische Daten hat das W3C das Element 'table' mitsamt Anverwandschaft bestimmt und kein "PRE" mit einer in ASCII gemalten Tabelle drin.

grundsätzlich gebe ich Dir ja recht. Aber ...

[x] ... ich mach's trotzdem.

- nur an die bestehenden Beispiele gehalten

Auch wenn alle anderen von der Bruecke springen wuerde ich mich doch noch vergewissern, ob sich darunter genuegend Wasser befindet.

- und war andererseits faul (so war nur copy & paste erforderlich)

Ja, deshalb ist es mir auch besonders aufgefallen. Ist bei Dir aber nicht gar so schlimm, wie beim Kollegen Rouven. Du hast immerhin noch die Entschuldigung, das Du die Ausgabe des DB-Admintools 1:1 darstellen wolltest. Die zieht aber auch wieder nicht, da es sich um eine allgemeine Behandlung des Problems handelt und nicht um einen Ausschnitt aus dem Benutzerhandbuch einer bestimmten DB.
Eine HTML-Tabelle laesst sich auch deutlich besser "aufhuebschen" wenn es um Hervorhebungen und aehnlichem geht.

so short

Christoph Zurnieden

[Vinzenz Mai]

Hallo Christoph,

... Du hast immerhin noch die Entschuldigung, das Du die Ausgabe des DB-Admintools 1:1 darstellen wolltest.

vielen Dank für Deinen Euphemismus, ich hätte den Begriff "faule Ausrede" verwendet. *bg*

Freundliche Grüße

Vinzenz

[Rouven]

N'Abend!

Hey, ich hab mir nur die Vorlage für die Artikel von der SelfHTML-Seite gezogen. Da das auf Code ausgerichtet ist, war für Beispiele diese Tabelle mit <pre>-Inhalt vorgesehen, bei der ich dann geblieben bin. Glaub mir, das zu tippen war lästiger als das in eine Tabelle zu platzieren. Aber ich wollt' ja nix falsch machen...

Wenn das nicht 'falsch' ist sondern nur aus Mangel an Verwendung nicht in der Vorlage vorkommt ändere ich es ab...

MfG
Rouven

[Tim Tepaße]

Hallo zusammen,

Damit bei eventuellen Änderungen am gleichen Artikelstand diskutiert werden kann, liegen beide Artikel jetzt in unserer internen Versionsverwaltung und sind - bevor sie dann entgültig veröffentlicht werden - auch unter diesen URLs online zu lesen:

Rouven Thimm, Einführung in Joins:
http://aktuell.de.selfhtml.org/artikel/review/datenbanken/joins/

Vinzenz Mai, Fortgeschrittenere Join-Techniken:
http://aktuell.de.selfhtml.org/artikel/review/datenbanken/fortgeschrittene-joins/

Etwaige Änderungen an den Artikeln werden sich dann an diesen Adressen finden. Danke für Eure Rückmeldungen.

Tim

[Rouven]

Hi,

wie geht das jetzt weiter, wenn ich da noch die besprochenen Änderungen dran mache, soll ich euch die dann schicken oder macht ihr ab jetzt weiter oder wie?

MfG
Rouven

[Tim Tepaße]

Hallo Rouven,

wie geht das jetzt weiter, wenn ich da noch die besprochenen Änderungen dran mache, soll ich euch die dann schicken oder macht ihr ab jetzt weiter oder wie?

Einfach an mich schicken, ich arbeite das dann ein. Ähm, das hatte ich Dir auch gestern abend per Mail geschrieben, ist die vielleicht verschütt gegangen?

Tim

[Rouven]

Hi Tim,

*hüstel*, ne, aber wenn ich bei der Arbeit im Intranet verschollen bin, dann ist das immer etwas schwer. War heute morgen nur ganz kurz am Terminal und hab ins Forum geschaut...
Hab die Mail gerade gesehen. Kümmere mich in der zweiten Wochenhälfte bzw. am Wochenende um alles weitere.

MfG
Rouven

[Ilja]

yo,

hmm, also die überschrift lautet einführung in JOINS (wobei das s dort klein geschrieben ist, wohl mit absicht, sieht aber schrecklich aus). aber das erste was ich lese ist, ein abschnitt über normalisierung. das ist sicherlich auch ein wichtiges thema, aber dort finde ich es deplaziert, zumal es ausfürlicher behandelt werden sollte. beim rechnnugsbetrag handelt es sich wohl um prozessdaten der einzelnen posten einer rechnung. alles im allen finde ich die einleitung der JOINS über die normalisierung nicht gut. wenn schon normalisierung erwähnen, dann in einem eigenen kapitel und ausführlicher.

des weiteren gehe ich konform mit daniela. ich denke begriffe wie relation sollten nicht einfach so verwendet werden, allerdings würde ich ihn stehen lassen und vorher erläutern. so schwer ist der begriff nicht zu verstehen. generell ist es so, dass viele begriffe in der datenverarbeitung falsch verwendet werden, selbst in vielen fachbüchern. deshalb solte man es ja mal richtig stellen. btw kreuzprodukt = karthesisches produkt und nicht jeder join ist ein karthesisches produkt. ausserdem würde ich einen join eher als verbindung (zusammenführung) als verbund übersetzen. aber das ist wohl geschmackssache.

das drängt sich mir die frage auf, ob man nicht einmal nägel mit köpfen macht und gleich ein kapitel über datenbanken schreibt, quasi bei adam und eva anfängt und das thema damit einleitet, was datenbanken eingentlich sind.

wie auch immer, zurück zu den JOINS. mir gefällt der artikel noch nicht so gut, auch wenn dort sehr viel arbeit drinne steckt. JOINS sind gerade für anfänger ein schwieriges kapitel und ich habe nicht den eindruck, dass es leicht verständlich rüber kommt.

des weiteren meine ich inhaltliche fehler zu erkennen, was aber noch zur diskussion stehen sollte. so werde meiner meinung nach JOINS nicht grundsätzlich von links nach rechts abgearbeitet. auch das die impliziete schreibweise nur für inner joins verwendet werden kann, würde ich einfach weglassen, da es nicht immer zutrifft. ein inner join ist kein equi join, auch wenn er meistens so angewandt wird. das sind aber zwei verschiedene paar schuhe. auch der vergleich mit dem karthesischen produkt hinkt. die menge eines equi joins kann dem eines karthesischen produktes gleichen. einfach weg lassen, es verwirrt nur.

weiter habe ich bis jetzt noch nicht gelesen, weil mir auch einige wichtige JOIN methoden fehlen.

Ilja

[Rouven]

N'Abend,

ich bleub bei meinem 'der Reihe nach'-Schema:

hmm, also die überschrift lautet einführung in JOINS (wobei das s dort klein geschrieben ist, wohl mit absicht, sieht aber schrecklich aus). aber das erste was ich lese ist, ein abschnitt über normalisierung. das ist sicherlich auch ein wichtiges thema, aber dort finde ich es deplaziert, zumal es ausfürlicher behandelt werden sollte. beim rechnnugsbetrag handelt es sich wohl um prozessdaten der einzelnen posten einer rechnung. alles im allen finde ich die einleitung der JOINS über die normalisierung nicht gut. wenn schon normalisierung erwähnen, dann in einem eigenen kapitel und ausführlicher.

Es wird ja, wie in den letzten Tagen häufiger debattiert, in der nächsten großen SelfHTML-Version ein eigenes DB-Kapitel geben. Da kann man sicherlich auch deinen Adam-und-Eva-Vorschlag bearbeiten. In diesem Fall war ja der Ausgangspunkt ein "wir können Anfänger dorthin verweisen"-Artikel. Mir persönlich erschien es sinnvoll am Anfang eine Motivation zu geben _warum_ man sich die Arbeit machen sollte, wenn die Sache mit den Joins doch so umständlich ist.
Bei der Sache scheinen die Meinungen auseinander zu gehen...

des weiteren gehe ich konform mit daniela. ich denke begriffe wie relation sollten nicht einfach so verwendet werden, allerdings würde ich ihn stehen lassen und vorher erläutern. so schwer ist der begriff nicht zu verstehen. generell ist es so, dass viele begriffe in der datenverarbeitung falsch verwendet werden, selbst in vielen fachbüchern. deshalb solte man es ja mal richtig stellen. btw kreuzprodukt = karthesisches produkt und nicht jeder join ist ein karthesisches produkt. ausserdem würde ich einen join eher als verbindung (zusammenführung) als verbund übersetzen. aber das ist wohl geschmackssache.

Siehe Antwort von gestern: Zielgruppenfrage, eher die Fachbegriffe raus. Eine Erklärung mit Fachbegriffen gibt es an vielen Stellen, wenn die Leute damit klar kämen gäbe es nicht so viele Fragen dazu. Dann lieber rausnehmen.

das drängt sich mir die frage auf, ob man nicht einmal nägel mit köpfen macht und gleich ein kapitel über datenbanken schreibt, quasi bei adam und eva anfängt und das thema damit einleitet, was datenbanken eingentlich sind.

...siehe oben.

wie auch immer, zurück zu den JOINS. mir gefällt der artikel noch nicht so gut, auch wenn dort sehr viel arbeit drinne steckt. JOINS sind gerade für anfänger ein schwieriges kapitel und ich habe nicht den eindruck, dass es leicht verständlich rüber kommt.

weil? was fehlt? welche Stelle?

des weiteren meine ich inhaltliche fehler zu erkennen, was aber noch zur diskussion stehen sollte. so werde meiner meinung nach JOINS nicht grundsätzlich von links nach rechts abgearbeitet. auch das die impliziete schreibweise nur für inner joins verwendet werden kann, würde ich einfach weglassen, da es nicht immer zutrifft. ein inner join ist kein equi join, auch wenn er meistens so angewandt wird. das sind aber zwei verschiedene paar schuhe. auch der vergleich mit dem karthesischen produkt hinkt. die menge eines equi joins kann dem eines karthesischen produktes gleichen. einfach weg lassen, es verwirrt nur.

Links-Rechts: Stimmt, das hängt auch vom Query-Optimizer ab, allerdings ist z.B. meine Erfahrung mit der DB2 so, dass X INNER JOIN Y INNER JOIN Z zu genau dieser Reihenfolge führt, sonst hätte ich in Vergangenheit doch so den ein oder anderen Datensatz verlieren müssen...
Die Sache mit der impliziten Schreibweise macht mir Kopfzerbrechen. Wenn es nach mir ginge, dann würden DBMS die nicht unterstützen. Aber man findet sie an vielen Stellen und muss sie denke ich irgendwo einordnen. Einen LEFT JOIN mit dieser Schreibweise zu reproduzieren habe ich nur ganz kurz probiert und dann lustlos direkt wieder sein lassen, weil es irgendwie nicht ganz so einfach ging.
Den Überblicksteil kann ich nochmal überarbeiten, nur wenn ich direkt mit einem INNER JOIN anfange geht das etwas zu schnell los. Man braucht einen sanften Einstieg, das karthesische Produkt schien mir da geeignet.

weiter habe ich bis jetzt noch nicht gelesen, weil mir auch einige wichtige JOIN methoden fehlen.

die da wären?

MfG
Rouven

[Vinzenz Mai]

Hallo Ilja,

wie auch immer, zurück zu den JOINS. mir gefällt der artikel noch nicht so gut, auch wenn dort sehr viel arbeit drinne steckt. JOINS sind gerade für anfänger ein schwieriges kapitel und ich habe nicht den eindruck, dass es leicht verständlich rüber kommt.

könntest Du das bitte präzisieren? D.h. Rouven und mir sagen, _woran_ der Einsteiger hängen bleibt, was dem Einsteiger nicht verständlich genug sein wird. Ich weiß, dass das sehr schwierig zu bewerten ist, wenn man in der Materie drinsteckt.

des weiteren meine ich inhaltliche fehler zu erkennen, was aber noch zur diskussion stehen sollte.

jetzt kommst Du auf den Punkt:

so werde meiner meinung nach JOINS nicht grundsätzlich von links nach rechts abgearbeitet.

ok, das könnte DBMS-abhängig sein. Und beim RIGHT JOIN vielleicht sogar grundsätzlich von rechts nach links? Ehrlich gesagt, weiß ich nicht, wie das DBMS das intern abarbeitet.

auch das die impliziete schreibweise nur für inner joins verwendet werden kann, würde ich einfach weglassen, da es nicht immer zutrifft.

wenn Du meinen allerersten Entwurf gelesen hast, dort habe ich einen Abschnitt über proprietäre Syntax geschrieben. LEFT/RIGHT bei MS SQL Server und Oracle, die neue USING-Syntax bei MySQL und PostgreSQL (wird die eigentlich von Oracle verstanden?).

ein inner join ist kein equi join, auch wenn er meistens so angewandt wird. das sind aber zwei verschiedene paar schuhe.

ich zitiere kurz aus meiner Antwort auf Danielas Posting

<zitat>

Fehlende Themen:

• Natural Joins

Vielleicht auf dem Weg von der Normalisierung zurück die Zwischenschritte Equijoin und Natürlicher Join (der Theorie) vorstellen. In den meisten Fällen wird man eher eine Projektion verwenden, die noch ein paar Spalten mehr ausblendet als nur die doppelte :-)
</zitat>

auch der vergleich mit dem karthesischen produkt hinkt. die menge eines equi joins kann dem eines karthesischen produktes gleichen. einfach weg lassen, es verwirrt nur.

Ich finde das kartesische Produkt schon wichtig, vor allem weil es gelegentlich unfreiwillig erzeugt wird, besonders von Anhängern der impliziten Joinsyntax.

hmm, also die überschrift lautet einführung in JOINS (wobei das s dort klein geschrieben ist, wohl mit absicht, sieht aber schrecklich aus). aber das erste was ich lese ist, ein abschnitt über normalisierung. das ist sicherlich auch ein wichtiges thema, aber dort finde ich es deplaziert, zumal es ausfürlicher behandelt werden sollte.

Diesen Weg fand ich nun wieder gut, weil er Joins motiviert. Es gibt genug Argumente der Form: "Joins, wozu brauch' ich das. Ich habe eh' alles in einer Tabelle!"

das drängt sich mir die frage auf, ob man nicht einmal nägel mit köpfen macht und gleich ein kapitel über datenbanken schreibt, quasi bei adam und eva anfängt und das thema damit einleitet, was datenbanken eingentlich sind.

Das war von Anfang an nicht Intention der neuen Artikel. Es ging bei diesen ganz speziell um die Joins. Auch weil es im Forum viele Fragen dazu gibt. Dass SELFHTML 9.0 ein solches Kapitel bekommen wird, ist ja angekündigt. Aber solange wollten Rouven und ich doch nicht warten.

Freundliche Grüße

Vinzenz, der um eine kritische Rezension seines Artikels bittet.

[Ilja]

yo Vinzenz & Rouven,

ich fasse euch beide mal zusammen. werde auch nur kurz antworten, weil es doch schon spät ist. was die verständlichkeit für anfänger betrifft, so ist es mehr ein gefühl als etwas konkretes. das wird euch wenig weiterhelfen, aber da muss ich erst einmal mir selbst helfen und der sache auf den grund gehen.

oracle arbeitet meines wissens die tabellen von rechts nach links ab. auch dort gibt es eine andere schreibweise einen OUTER JOIN zu verwirklichen, mann muss nicht die typische OUTER JOIN ...ON syntax benutzen, auch wenn Oracle diese nun beherscht. das hat zum teil erheblichen einfluss auf die performance einer abfrage. wie auch immer, ich würde das thema impliziet oder aber reihenfolge einfach weglassen, wenn es um JOINS für anfänger geht. das geht eher in richtung optimierung.

ein inner join ist kein equi join, auch wenn er meistens so angewandt wird. das sind aber zwei verschiedene paar schuhe.

ich zitiere kurz aus meiner Antwort auf Danielas Posting

<zitat>

Fehlende Themen:

• Natural Joins

Vielleicht auf dem Weg von der Normalisierung zurück die Zwischenschritte Equijoin und Natürlicher Join (der Theorie) vorstellen. In den meisten Fällen wird man eher eine Projektion verwenden, die noch ein paar Spalten mehr ausblendet als nur die doppelte :-)
</zitat>

ein natural join hat erst einmal wenig mit der unterscheidung zwischen einem equi join und einem inner join zu tun, auch wenn er natürlich diese methoden verwendet. grundsätzlich unterscheidet man zwischen einem equi und non-equi join. man kann die tabellen nämlich auch mit < oder > operatoren verknüpfen. oder mit anderen worten ein inner join wird sicherlich meistens ein equi join sein, das ist der outer join aber auch. equi steht quasi für die verwendung des '=' zeichen.

Ich finde das kartesische Produkt schon wichtig, vor allem weil es gelegentlich unfreiwillig erzeugt wird, besonders von Anhängern der impliziten Joinsyntax.

sicherlich ist die erwähnung des karthesischen produktes wichtig, aber dann doch auch im richtigen zusammenhang.

Diesen Weg fand ich nun wieder gut, weil er Joins motiviert. Es gibt genug Argumente der Form: "Joins, wozu brauch' ich das. Ich habe eh' alles in einer Tabelle!"

das widerspricht euch aber ein wenig selbst. zum einen sagt ihr, fachbegriffe raus halten, weil es eben in der hauptsache um joins geht und man auf dieses kapitel verweisen will. wenn man nun aber auf dieses kapitel verweißt, dann doch nur, weil jemand schon konkrete fragen zu einem JOIN hat, man muss quasi das bedürfniss nicht mehr erzeugen, wie enstehen joins. ich würde die normalisierung komplett weglassen, ist ein verwirrendes thema für sich.

ok, nun aber ab ins bett, brauche schlaf....

Ilja

[Matzberger Marcus]

Hallo,

wenn Du meinen allerersten Entwurf gelesen hast, dort habe ich einen Abschnitt über proprietäre Syntax geschrieben. LEFT/RIGHT bei MS SQL Server und Oracle, die neue USING-Syntax bei MySQL und PostgreSQL (wird die eigentlich von Oracle verstanden?).

Ja, seit 9i. Hier ein kurzer Auszug aus der Doku:

»»SELECT d.department_id as d_dept_id

,e.department_id as e_dept_id
     ,e.last_name

»»FROM   departments d FULL OUTER JOIN employees e
»»ON     d.department_id = e.department_id
»»ORDER BY d.department_id;
»»
»»
»»Because the column names in this example are the same in both tables in the join,
»»you can also use the common column feature (the USING clause) of the join syntax,
»»which coalesces the two matching columns department_id. The output is the
»»same as for the preceding example:
»»
»»SELECT department_id AS d_e_dept_id

,e.last_name

»»FROM   departments d FULL OUTER JOIN employees e
»»USING (department_id)
»»ORDER BY department_id;

Beschreibung der verschiedenen Joins bei Oracle

Grüße
Marcus

[Vinzenz Mai]

Hallo Marcus,

erstmal recht herzlichen Dank für die Info.

wenn Du meinen allerersten Entwurf gelesen hast, dort habe ich einen Abschnitt über proprietäre Syntax geschrieben. LEFT/RIGHT bei MS SQL Server und Oracle, die neue USING-Syntax bei MySQL und PostgreSQL (wird die eigentlich von Oracle verstanden?).

Ja, seit 9i. Hier ein kurzer Auszug aus der Doku:

Da nervt mich stets das "Please sign in!" :-)

Ok, wenn schon einmal drei relevante DBMS USING unterstützen, so sollte dies in einem der Artikel dokumentiert sein. Ähnliches gilt für den NATURAL JOIN. Da hatte ich offensichtlich oft genug Scheuklappen an. Ich kenne den natürlichen Join in der Bedeutung wie er in Wikipedia nachzulesen ist, der wenig mit der NATURAL-JOIN-Syntax der DBMS zu tun hat. Obwohl ich mir oft genug in der MySQL-Doku zur Join-Syntax gelesen habe, habe ich den NATURAL JOIN stets überlesen :-( Auch hier gilt: sollte aufgenommen werden (da zumindest gleiche Unterstützung vorhanden: MySQL, PostreSQL, Oracle).

Freundliche Grüße

Vinzenz

[Matzberger Marcus]

Hallo,

Ja, seit 9i. Hier ein kurzer Auszug aus der Doku:

Da nervt mich stets das "Please sign in!" :-)

Fiel mir nicht auf, da sich mein Arbeitsplatzrecher per Cookie dort ausweist. Daher habe ich auch nicht darauf hingewiesen. Aber die Anmeldung kostet zumindest nichts;-)

Grüße
Marcus

[Vinzenz Mai]

Hallo Marcus,

Da nervt mich stets das "Please sign in!" :-)
Fiel mir nicht auf, da sich mein Arbeitsplatzrecher per Cookie dort ausweist. Daher habe ich auch nicht darauf hingewiesen. Aber die Anmeldung kostet zumindest nichts;-)

Ja hab' ich inzwischen auch gemerkt, und mich mal bei den Downloads umgesehen :-)

Freundliche Grüße

Vinzenz

[Matzberger Marcus]

Hallo,

Ja hab' ich inzwischen auch gemerkt, und mich mal bei den Downloads umgesehen :-)

Insbesondere die kostenlose Oracle Express Edition ist ganz interessant. Aktuell nur Beta, aber zum Rumprobieren reichts. Und die Einschränkung auf 4 GB Userdaten, 1 Prozessor und 1 GB RAM sollten für den Einstieg auch ausreichen.

Grüße
Marcus

[Ilja]

yo,

unabhängig von den guten tipp eine oracle version zu bekommen, würde ich versuchen die unterschiedlichen dialekte nach möglichkeit erst am ende zu präsentieren und mich an ansi92 orientieren. dann hat man erst einmal einen leitfaden.

Ilja

[Rouven]

Hi,

volle Zustimmung, zumal es auch vom Lernen her sinnvoller ist das zunächst einmal unabhängig vom DBMS zu verstehen, Rafinessen kann man dann immer noch später ausnutzen.

Wen's interessiert: Von der DB2 gibts auch so eine Personal Edition mit ähnlichen Beschränkungen zum Download (ca. 550MB), müsste v8.x sein.

MfG
Rouven

[Vinzenz Mai]

Hallo Rouven,

Wen's interessiert: Von der DB2 gibts auch so eine Personal Edition mit ähnlichen Beschränkungen zum Download (ca. 550MB), müsste v8.x sein.

mich interessiert es :-) Danke, ich habe den Download gefunden (noch 'ne Registrierung mehr).

Freundliche Grüße

Vinzenz

[Daniela Koller]

Hi Rouven

Wen's interessiert: Von der DB2 gibts auch so eine Personal Edition mit ähnlichen Beschränkungen zum Download (ca. 550MB), müsste v8.x sein.

Entspricht die PC-Version vom Funktionsumfang und den SQL-Möglichkeiten eigentlich der MVS/OS390/zOS-Variante? So im nachhinein betrachtet, konnte die MVS-Version schon 1997 sehr viel, deutlich mehr als MySQL heute in der 5er-Version beherrscht.

Gruss Daniela

[Vinzenz Mai]

Hallo

Wen's interessiert: Von der DB2 gibts auch so eine Personal Edition mit ähnlichen Beschränkungen zum Download (ca. 550MB), müsste v8.x sein.

Dank Eurer Hinweise habe ich meine Beispiele umgeschrieben, so dass ich sie unter

- MySQL 5.0.16 und 4.1.18
  - PostgreSQL 8.1
  - Microsoft SQL Server 2000 und 2005
  - Oracle XE 10g Release 2
  - DB2 PE v8.2.2

erfolgreich ausführen konnte.

volle Zustimmung, zumal es auch vom Lernen her sinnvoller ist das zunächst einmal unabhängig vom DBMS zu verstehen, Rafinessen kann man dann immer noch später ausnutzen.

Ich bin gleicher Meinung, trotzdem habe ich einen Abschnitt in Angriff genommen, der sich mit den abkürzenden Schreibweisen USING und NATURAL JOIN befasst.

Freundliche Grüße

Vinzenz