Announcement

Collapse
No announcement yet.

Beispiel mit "Natural Join" und "IN" intern unterschiedlich umgesetzt ?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Beispiel mit "Natural Join" und "IN" intern unterschiedlich umgesetzt ?

    Gegeben ist folgendes relationales Schema:

    Buch(BuchID, AID->Autor, Titel)
    Autor(AutorID, Vorname, Nachname)

    Gesucht ist ein SQL Query der folgende Frage beantwortet: "Welche Bücher wurden von Autoren mit dem Vornamen "Peter" geschrieben ?

    Variante 1 (Natural Join):

    Code:
    SELECT BuchID
    FROM Buch,Autor
    WHERE AID = AuthorID AND Vorname='Peter'
    Variante 2 (IN):

    Code:
    SELECT BuchID
    FROM Buch
    WHERE AID in (SELECT AutorID FROM Autor WHERE Vorname='Peter'
    __________________________________________________ ____________

    Nun zur Frage: Gibt es einen Unterschied zwischen den beiden Varianten oder werden sie intern gleich umgesetzt bzw. ist eine von beiden peformanter ?

  • #2
    Die Frage finde ich auch sehr interessant. Ich stand auch schon öfters vor dem Problem das entscheiden zu müssen.
    Bin gespannt was die Oracle Experten dazu sagen.

    Ich hätte noch einen weiteren Vorschlag:
    Code:
    with GefundeneAutoren as
    (
      SELECT AutorID FROM Autor WHERE Vorname='Peter'
    )
    SELECT BuchID
    FROM Buch,GefundeneAutoren
    WHERE Buch.AID = GefundeneAutoren.AuthorID

    Comment


    • #3
      Eine Natural Join würde ich nie verwenden. Ändert sich hier z.B. der Spaltenname, wird aus dem Inner Join ein Kartesisches Produkt. Außerdem weiß jemand der das Datenmodell nicht in und auswendig kennt nicht was der Autor den eigentlich wollte.
      Wenn ich einen Inner Join haben möchte, dann schreib ich das auch.

      Ich stand auch schon öfters vor dem Problem das entscheiden zu müssen.
      Da gibts nix zu entscheiden. Join Bedingung angeben und fertig.

      Ich hätte noch einen weiteren Vorschlag
      Da gilt das gleiche wie oben.

      Comment


      • #4
        Das Schlimme ist ja, dass man genau diese Art Join wie dort oben leider überall sieht. Wenn keine tieferen Einblicke in SQL Tuning bzw. Administration hat, dann hat man leider auch nicht den blassesten Schimmer, welche Abfrage denn nun performanter ist.

        Wie würdest Du denn die Abfrage formulieren?

        Comment


        • #5
          Oracle optimiert solche Konstrukte meistens immer gleich um. Wenn Du einen Join möchtest, dann mach es auch einfach.
          Wenn Du ein Zwischenergebniss öfters brauchst, dann kannst Du Subquery Factoring verwenden.

          Zu sagen das Konstrukt X ist performanter als Y ist nicht möglich, denn ansonsten würde jeder Datenbankhersteller Y nicht erlauben oder intern umschreiben.

          Natural Joins sollte man auf jeden Fall immer vermeiden, da sie zum einen für ungewollte kartesische Produkte sorgen können (oder das auch schon tun und man deshalb mit einem distinct nochmal eindampft etc. etc.) und sie zum anderen das Statement

          Comment


          • #6
            Gegeben sei folgendes Beispiel:
            Buch(BuchID, AID->Autor, Titel)
            Autor(AID, Vorname, Nachname)
            Der Spaltenname von Autor wurde bewußt von AutorID in AID geändert.

            Ein Inner Join kann wie folgt geschreiben werden:
            Oracle-Schreibweise:
            SELECT BuchID
            FROM Buch b, Autor a
            WHERE b.AID = a.AID AND a.Vorname='Peter';

            oder
            SQL-Standardschreibweise:
            SELECT BuchID
            FROM Buch b JOIN Autor a ON (b.AID = a.AID)
            WHERE a.Vorname='Peter';

            Ein Natural Join wird in der SQL-Standardschreibweise so angegeben:

            SELECT BuchID
            FROM Buch b NATURAL JOIN Autor a
            WHERE a.Vorname='Peter';

            Für das konkrete Beispiel könnte die Abfrage auch so geschrieben werden, wobei es sich hier nicht um einen Natural Join handelt.

            SELECT BuchID
            FROM Buch b JOIN Autor a USING (AID)
            WHERE a.Vorname='Peter';


            Wird jetzt die Spalte AID von Autor in AutorID geändert, so liefern die Abfragen (außer Natural Join) keine Ergebniszeilen. Da der Natural Join keine gleichen Spaltennamen in beiden Tabellen findet, verknüpft er jeden Datensatz der einen Tabelle mit jedem Datensatz der anderen Tabelle. Er bildet also ein Kartesisches Produkt.


            "Strukturänderungen sind tödlich." In einer bestehenden Datenbank sollte auf Strukturänderungen verzichtet werden.


            Die WITH-Anweisung macht wenig Sinn, wenn "GefundeneAutoren" nur einmal verwendet wird.

            kuemmelchen

            Comment


            • #7
              Aso unter NATURAL JOIN versteht man den Join bei dem die Datenbank automatisch die beiden Spalten "matched". Das würde ich sowieso nie machen, auch wenn bei mir alle gleich heissen.

              Dass das WITH nicht unbedingt benötigt wird sehe ich auch, allerdings finde ich das schöner als ein ellenlanges SELECT Kommando (hier hätte ich es bestimmt auch als "Unterabfrage" formuliert)

              Comment


              • #8
                Aso unter NATURAL JOIN versteht man den Join bei dem die Datenbank automatisch die beiden Spalten "matched". Das würde ich sowieso nie machen, auch wenn bei mir alle gleich heissen.
                Ein Natural Join verknüpft alle!!! gleichnamigen Spalten aus beiden Tabellen miteinander.

                Beispiel:
                Mann (id, vorname, nachname)
                Frau (id, vorname, nachname)

                SELECT *
                FROM Mann m NATURAL JOIN Frau f;

                entspricht:

                SELECT *
                FROM Mann m, Frau f
                WHERE m.id = f.id
                AND m.vorname = f.vorname
                AND m.nachname = f.nachname;

                kuemmelchen

                Comment


                • #9
                  Uuuuuh *grusel* Ok... das ist nix gut. Ausser natürlich man will das haben, aber dann sollte man das auch explizit hinschreiben.

                  Ich glaube ich sollte mal wieder ein bischen im SQL Tuning Buch lesen *g*

                  sooo viel zu lesen... puuuh...

                  Comment

                  Working...
                  X