自然結合と内部結合の違いは何ですか?
自然結合と内部結合の違いは何ですか?
回答:
INNER JOINとNATURAL JOINの重要な違いの1つは、返される列の数です。
考慮してください:
TableA                           TableB
+------------+----------+        +--------------------+    
|Column1     | Column2  |        |Column1  |  Column3 |
+-----------------------+        +--------------------+
| 1          |  2       |        | 1       |   3      |
+------------+----------+        +---------+----------+INNER JOIN列1のテーブルAとテーブルBの戻ります
SELECT * FROM TableA AS a INNER JOIN TableB AS b USING (Column1);
SELECT * FROM TableA AS a INNER JOIN TableB AS b ON a.Column1 = b.Column1;+------------+-----------+---------------------+    
| a.Column1  | a.Column2 | b.Column1| b.Column3|
+------------------------+---------------------+
| 1          |  2        | 1        |   3      |
+------------+-----------+----------+----------+NATURAL JOIN列1のテーブルAとテーブルBのは返します。
SELECT * FROM TableA NATURAL JOIN TableB
+------------+----------+----------+    
|Column1     | Column2  | Column3  |
+-----------------------+----------+
| 1          |  2       |   3      |
+------------+----------+----------+列の繰り返しは避けられます。
(標準文法のAFAICTでは、自然結合では結合列を指定できません。結合は厳密に名前ベースです。Wikipediaも参照してください。)
(チートは出力を内部結合であります; a.およびb.部品は、列名にはならないでしょう。あなただけの必要があるだろうcolumn1、column2、column1、column3見出しとして。)
NATURAL JOINに何が台無しになるのか、なぜそれが予想外であるのか、そしてあなたがどの世界にいるのかについて詳しく説明できますか?
                    CustomersとEmployeesしEmployeeIDます。  フィールドEmployeesもありManagerIDます。全部大丈夫です。その後、ある日、誰かがテーブルにManagerIDフィールドを追加しCustomersます。あなたの結合は壊れません(それは慈悲でしょう)、代わりにそれは2番目のフィールドを含み、正しく動作しません。したがって、一見害のない変更によって、関連性の低いものだけが破壊される可能性があります。ひどい。自然結合の唯一の利点は、タイピングを少し節約することであり、欠点はかなりあります。
                    SELECT * FROM TableA INNER JOIN TableB USING (Column1)が4列を与えると述べました。SELECT * FROM TableA INNER JOIN TableB USING (Column1)とSELECT * FROM TableA NATURAL JOIN TableBは等しいため、これは正しくありません。どちらも3列です。
                    natural leftかnatural right)であることを参加の条件を前提としているところ、両方のテーブルの試合で同じ名前の列ペストのような自然結合の使用は避けます。自然結合は次のとおりです。
NATURAL JOIN Checkouts"は、データベースの命名規則が正式で強制されている場合にのみ可能です。..."
                    idユビキタスであり、参加するのに役に立たないため、実際には役に立たない 通常の外部キー名はtablename_idです。自然結合は悪い、悪い、悪い考えです。
                    自然結合は入力を回避するための単なるショートカットであり、結合は単純で、同じ名前のフィールドに一致すると想定されています。
SELECT
  *
FROM
  table1
NATURAL JOIN
  table2
    -- implicitly uses `room_number` to joinと同じです...
SELECT
  *
FROM
  table1
INNER JOIN
  table2
    ON table1.room_number = table2.room_numberただし、ショートカット形式ではできないのは、より複雑な結合です...
SELECT
  *
FROM
  table1
INNER JOIN
  table2
    ON (table1.room_number = table2.room_number)
    OR (table1.room_number IS NULL AND table2.room_number IS NULL)NATURAL JOIN ... USING ()ですか。標準のいずれかであるa NATURAL JOIN bかa JOIN b USING (c)
                    room_numberあるのに対し、内部結合にはという名前の列が2つありますroom_number。
                    SQLは、多くの点でリレーショナルモデルに忠実ではありません。SQLクエリの結果はリレーションではありません。重複した名前の列、「匿名の」(名前のない)列、重複した行、nullなどがある可能性があります。SQLは、列の順序などに依存しているため、テーブルをリレーションとして扱いません。
NATURAL JOINSQLの背後にある考え方は、リレーショナルモデルにより忠実になることを容易にすることです。NATURAL JOIN2つのテーブルの結果には、名前によって重複が排除された列が含まれるため、匿名の列はありません。同様に、UNION CORRESPONDINGそしてEXCEPT CORRESPONDINGレガシーで列の順序でアドレスSQLの依存に提供されていますUNION構文。
ただし、すべてのプログラミング手法と同様に、有用であるためには規律が必要です。NATURAL JOIN結合が同じ名前の列に暗黙的に含まれるため、成功するための1つの要件は、一貫して名前が付けられた列です(SQLで列の名前を変更する構文が冗長であることは残念ですが、副作用として、ベーステーブルの列に名前を付けるときの規則が奨励されます。VIEW s :)
SQL NATURAL JOINは等結合**ですが、これは有用性を妨げるものではありません。NATURAL JOINSQLでサポートされる唯一の結合タイプである場合でも、関係的に完全であることを考慮してください。。
実際に、プロジェクション()NATURAL JOINを使用INNER JOINして記述できることは事実ですが、製品()および制限()を使用して記述できることSELECTも事実です。さらに、共通の列名のないテーブル間では、と同じ結果が得られることに注意してください。したがって、リレーションである結果のみに関心がある場合(そして、なぜそうならないのか?!)、必要な結合タイプはこれだけです。確かに、言語設計の観点からは、やなどの省略形があることは事実ですが、ほとんどすべてのSQLクエリは、構文的には異なりますが、意味的には同等の10の方法で記述できることを考慮してください。これがSQLオプティマイザを非常に困難にしている理由です。開発する。INNER JOINCROSS JOINWHERENATURAL JOINCROSS JOINNATURAL JOININNER JOINCROSS JOIN
以下は、意味的に同等なクエリの例です(通常の部品とサプライヤーデータベースを使用)。
SELECT *
  FROM S NATURAL JOIN SP;
-- Must disambiguate and 'project away' duplicate SNO attribute
SELECT S.SNO, SNAME, STATUS, CITY, PNO, QTY
  FROM S INNER JOIN SP 
          USING (SNO);                        
-- Alternative projection
SELECT S.*, PNO, QTY
  FROM S INNER JOIN SP 
          ON S.SNO = SP.SNO;
-- Same columns, different order == equivalent?!
SELECT SP.*, S.SNAME, S.STATUS, S.CITY
  FROM S INNER JOIN SP 
      ON S.SNO = SP.SNO;
-- 'Old school'
SELECT S.*, PNO, QTY
  FROM S, SP 
 WHERE S.SNO = SP.SNO;**リレーショナル自然結合は、等結合ではなく、1の射影です。– philipxy
NATURAL参加のためにわずか構文される特定の INNER参加-又は「等結合」 -と、構文が開封されると、両方同じ関係代数演算を表します。これは、「異なる種類の」結合ではありません。OUTER(LEFT/ RIGHT)やCROSS結合の。
を参照してください 等結合ウィキペディアのセクションを:
自然結合は、等結合のさらなる特殊化を提供します。結合述語は、結合されたテーブルで同じ列名を持つ両方のテーブルのすべての列を比較することによって暗黙的に発生します。結果の結合テーブルには、同じ名前の列のペアごとに1つの列のみが含まれます。
ほとんどの専門家は、NATURAL JOINは危険であり、そのため使用を強く推奨しないことに同意します。危険なのは、別の列と同じ名前の新しい列を誤って追加したことです...
つまり、すべてのNATURALように書くことも加わりINNER参加する(その逆は真ではありません)。そのためには、述語を作成するだけです明示的に   -例:USINGまたはON -)。Jonathan Lefflerが指摘したように、必要な結果セットの列を選択して、必要に応じて「重複」を回避します。
ハッピーコーディング。
(NATURALキーワードはLEFTand RIGHT結合にも適用できます。同じことが適用されます。NATURAL LEFT/RIGHT結合は、特定の LEFT/RIGHT結合の短い構文にすぎません。)
内部結合と自然結合はほとんど同じですが、両者にはわずかな違いがあります。違いは、条件を指定する必要がない自然結合ですが、内部結合条件では必須です。内部結合で条件を指定すると、結果のテーブルはデカルト積のようになります。
mysql> SELECT  * FROM tb1 ;
+----+------+
| id | num  |
+----+------+
|  6 |   60 |
|  7 |   70 |
|  8 |   80 |
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
+----+------+
6 rows in set (0.00 sec)
mysql> SELECT  * FROM tb2 ;
+----+------+
| id | num  |
+----+------+
|  4 |   40 |
|  5 |   50 |
|  9 |   90 |
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
+----+------+
6 rows in set (0.00 sec)INNER JOIN:
mysql> SELECT  * FROM tb1 JOIN tb2 ; 
+----+------+----+------+
| id | num  | id | num  |
+----+------+----+------+
|  6 |   60 |  4 |   40 |
|  7 |   70 |  4 |   40 |
|  8 |   80 |  4 |   40 |
|  1 |    1 |  4 |   40 |
|  2 |    2 |  4 |   40 |
|  3 |    3 |  4 |   40 |
|  6 |   60 |  5 |   50 |
|  7 |   70 |  5 |   50 |
|  8 |   80 |  5 |   50 |
.......more......
return 36 rows in set (0.01 sec) 
AND NATURAL JOIN :
    mysql> SELECT  * FROM tb1 NATURAL JOIN tb2 ;
    +----+------+
    | id | num  |
    +----+------+
    |  1 |    1 |
    |  2 |    2 |
    |  3 |    3 |
    +----+------+
    3 rows in set (0.01 sec)