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
-------------------
ss:) zu:) ls:& fo:) de:< va:{ ch:? sh:) n4:( rl:? br:$ js:| ie:) fl:(