SQL ANSI-92標準がANSI-89よりも適切に採用されないのはなぜですか？

私が働いたすべての会社で、人々はまだANSI-89標準でSQLクエリを書いていることがわかりました。

select a.id, b.id, b.address_1
from person a, address b
where a.id = b.id

ANSI-92標準ではなく：

select a.id, b.id, b.address_1
from person a
inner join address b
on a.id = b.id

このような非常に単純なクエリの場合、読みやすさに大きな違いはありませんが、大規模なクエリの場合、結合条件をグループ化してテーブルを一覧表示すると、結合のどこに問題があるかを簡単に確認できることがわかります。すべてのフィルタリングをWHERE句で維持しましょう。言うまでもなく、外部結合はOracleの（+）構文よりも直感的です。

ANSI-92を人々に伝道しようとすると、ANSI-89よりもANSI-92を使用した方がパフォーマンスに具体的なメリットはありますか？私は自分で試してみますが、ここにあるOracleのセットアップではEXPLAIN PLANを使用できません-人々がコードを最適化しようとしないでください。

Peter GulutzanとTrudy Pelzerによる "SQL Performance Tuning"によると、彼らがテストした6つまたは8つのRDBMSブランドのうち、SQL-89とSQL-92スタイルの結合の最適化またはパフォーマンスに違いはありませんでした。ほとんどのRDBMSエンジンは、クエリを最適化または実行する前に構文を内部表現に変換するので、人間が読める構文には違いがありません。

また、SQL-92構文を伝道しようとしています。それが承認されてから16年が経ち、人々はそれを使い始めました！SQLデータベースのすべてのブランドがこれをサポートするようになったため、非標準の(+)Oracle構文または*=Microsoft / Sybase構文を引き続き使用する理由はありません。

SQL-89習慣の開発者コミュニティを打ち破るのが非常に難しい理由については、本や雑誌の記事の古代の例を使用して、コピー＆ペーストでコーディングするプログラマーの大規模な「ピラミッドのベース」があるとしか思えません。または別のコードベース、そしてこれらの人々は抽象的に新しい構文を学びません。パターンマッチする人もいれば、暗記する人もいます。

けれども、SQL-92構文を以前よりも頻繁に使用している人たちが徐々に見えてきています。私は1994年以来オンラインでSQLの質問に答えてきました。

ANSI092標準にはかなり厄介な構文が含まれています。自然結合とUSING句は別のものです。私見、テーブルへの列の追加はコードを壊すべきではありませんが、NATURAL JOINは最も悪質な方法で壊れます。ブレークする「最善の」方法は、コンパイルエラーによるものです。たとえば、あなたが*どこかを選択した場合は、列の追加はできましたコンパイルに失敗しました。失敗する次善の方法は、実行時エラーです。ユーザーには表示される可能性があるため、さらに悪いことですが、何かが壊れているという警告が表示されます。ANSI92を使用し、NATURAL結合を使用してクエリを作成する場合、コンパイル時にブレークせず、実行時にブレークせず、クエリは突然誤った結果を生成し始めます。これらのタイプのバグは潜行性です。レポートが間違っている、潜在的に財務情報の開示が正しくない。

NATURALジョインに不慣れな方のために。両方のテーブルに存在するすべての列名で2つのテーブルを結合します。4列のキーがあり、それを入力するのにうんざりしている場合、これは本当にクールです。Table1にDESCRIPTIONという名前の既存の列があり、Table2という名前の新しい列を追加したときに問題が発生します。わかりません、mmm、DESCRIPTIONのような無害なもので、VARCHAR2の2つのテーブルを結合しています（1000）自由形式のフィールド。

USING句は、上記の問題に加えて、完全なあいまいさをもたらす可能性があります。別のSOの投稿で、誰かがこのANSI-92 SQLを示し、それを読むのを手伝ってほしいと頼んだ。

SELECT c.* 
FROM companies AS c 
JOIN users AS u USING(companyid) 
JOIN jobs AS j USING(userid) 
JOIN useraccounts AS us USING(userid) 
WHERE j.jobid = 123

これは完全にあいまいです。会社とユーザーの両方のテーブルにUserID列を配置しましたが、文句はありません。会社のUserID列がその行を最後に変更した最後の人のIDである場合はどうなりますか？

私は真面目です、なぜそのような曖昧さが必要だったのか誰か説明できますか？なぜ標準に直接組み込まれているのですか？

私はビルが正しいと思います。コーディングを通してそこにコピー/ペーストする開発者の大きな基盤があるということです。実際、ANSI-92に関して言えば、私は一種だと認めることができます。これまでに見たすべての例では、複数の結合が括弧内にネストされていました。正直なところ、SQLでテーブルを選択することはせいぜい困難です。しかし、SQL92 evangilistは、それが実際に結合順序を強制するだろうと説明しました。JESUS ...私が見たこれらすべてのコピーペースターは、実際には結合順序を強制しています。つまり、ジョブの95％が、オプティマイザ（特にコピー/ペースト）に委ねられています。

トマラックは彼が言ったときにそれを正しく理解しました、

そこにあるからといって、人々は新しい構文に切り替えない

それは私に何かを与える必要があり、私は上向きを見ていません。そして、良い面があれば、ネガティブは無視できない大きすぎるアホウドリです。

いくつかの理由が思い浮かびます：

• 人々は習慣からそれをします
• 人々は怠惰で、タイピングが少ないため「古いスタイル」の結合を好みます
• 初心者はしばしばSQL-92結合構文に頭を抱える問題を抱えています
• そこにあるからといって、人々は新しい構文に切り替えない
• 新しい構文（呼び出したい場合）には、主に外部結合を行う前にテーブルをフィルターすることができ、WHERE句がある場合にテーブルをフィルター処理できるという利点があることに人々は気づいていません。

私の部分では、SQL-92構文ですべての結合を行い、可能な場合はコードを変換します。それは、よりクリーンで読みやすく、強力な方法です。しかし、クエリの結果を変更せずに入力作業を増やすという点で、新しいスタイルを使用するように説得するのは困難です。

上記のNATURAL JOINおよびUSINGの投稿に対応して。

なぜこれらを使用する必要があると思いますか。これらはANSI-89では使用できず、ANSI-92に追加されたのは、私がショートカットとしてしか見えないためです。

私は結合を偶然に残さず、常にテーブル/エイリアスとIDを指定します。

私にとって、唯一の方法はANSI-92です。それはより冗長で、構文はANSI-89フォロワーには好まれませんが、JOINSとFILTERINGを適切に分離します。

まず、SQL Serverでは、外部結合構文（* =）が常に正しい結果を提供するとは限りません。それを外部結合ではなくクロス結合として解釈する場合があります。ですから、使用をやめるのには十分な理由があります。そして、その外部結合構文は非推奨の機能であり、SQL Server 2008以降のSQL Serverの次のバージョンには含まれません。内部結合を実行することはできますが、いったい誰がそうしたいのでしょうか。それらは不明確で、維持するのがはるかに困難です。結合の一部が何であり、本当にwhere句だけなのかは簡単にはわかりません。

古い構文を使用してはならない理由の1つは、結合と、結合の機能と非機能を理解することが、SQLコードを書く人にとって重要なステップであることです。結合を完全に理解せずにSQLコードを記述しないでください。それらをよく理解していれば、ANSI-92構文の方が明確で維持しやすいという結論に達するでしょう。古い構文よりもANSI-92構文を使用しなかったSQLの専門家に会ったことはありません。

古いコードを使用する、私が会った、または対応したほとんどの人は、結合を本当に理解していないため、データベースのクエリを実行するときに問題が発生します。これは私の個人的な経験なので、いつもそうだとは言いません。しかし、データスペシャリストとして、私はこのジャンクを信じられないほど長年に渡って修正しなければなりませんでした。

私は学校でANSI-89を教えられ、業界で数年間働きました。その後、DBMSのすばらしい世界を8年間離れました。しかし、それから私は戻ってきて、この新しいANSI 92のことを教えられていました。Join On構文を学びましたが、今では実際にSQLを教えており、新しいJOIN ON構文を推奨しています。

しかし、私が見ている欠点は、相関サブクエリがANSI 92結合の観点からは意味をなさないように見えることです。結合情報がWHEREに含まれていて、相関サブクエリがWHEREで「結合」されている場合、すべて正しく正しく一貫しているように見えました。ANSI 92テーブルの結合基準がWHEREになく、サブクエリの "結合"がある場合、構文に一貫性がないように見えます。一方、この不整合を「修正」しようとすると、おそらくさらに悪化します。

確かに答えはわかりません。これは宗教戦争です（Mac-Pcや他のものよりも程度が低い）。

かなり最近まで、Oracle（およびおそらく他のベンダーも）はANSI-92標準を採用していなかった（私はそれがOracle v9またはそのあたりだったと思う）ので、DBAやDB開発者は、まだこれらのバージョンを使用していた（またはこれらのバージョンを使用している可能性のあるサーバー間でコードを移植可能にしたかったため、古い標準に準拠する必要があった...

新しい結合構文はより読みやすく、古い構文は誤って（正しくない）結果を生成するため、よく文書化されたシナリオがいくつかあります。

• 具体的には、結合の「外部」側のテーブルからの非結合関連の列に条件付きフィルタリング述語がある場合の外部結合。

慣性と実用性。

ANSI-92 SQLはタッチタイピングに似ています。理論的にはいつの日かすべてが良くなるかもしれませんが、4本の指でキーを見る方がずっと速くタイプできるようになりました。前進するためには後退する必要がありますが、見返りがあるとは限りません。

SQLを書くことは私の仕事の約10％です。ANSI-89 SQLで解決できない問題をANSI-92 SQLで解決する必要がある場合は、それを使用します。（実際、Accessで使用しています。）常に使用すると、既存の問題をより迅速に解決できる場合は、時間をかけて同化します。しかし、構文について考えることなくANSI-89 SQLを作成できます。SQL構文について考えることは私の時間と私の雇用者のお金の無駄です。

いつか、若いグラスホッパー、あなたはANSI-92 SQL構文の使用を、SQL3（または何でも）を使用すべきであると非難する若者に対して擁護するでしょう。そして、あなたは理解するでしょう。:-)

元々SQL Server 6.5用に作成されたクエリがあり、SQL 92結合構文をサポートしていませんでした。

select foo.baz
from foo
  left outer join bar
  on foo.a = bar.a

代わりに

select foo.baz
from foo, bar
where foo.a *= bar.a

クエリはしばらくの間存在し、関連データが蓄積されてクエリの実行が遅くなりすぎて、完了までに90秒かかりました。この問題が発生するまでに、SQL Server 7にアップグレードしていました。

インデックスやその他のイースターエッグをいじった後、結合構文をSQL 92準拠に変更しました。クエリ時間は3秒に減少しました。

切り替えるのには十分な理由があります。

ここから転載。

私は平均的な開発者の観点から答えることができます。両方の構文を理解するのに十分なSQLを知っていますが、それでも、必要なときに毎回、挿入の正確な構文をグーグルで調べます... :-P（私はSQLを終日しません） 、いくつかの問題を時々修正するだけです。）

まあ、実際には、最初のフォームの方が直感的で、2つのテーブル間の階層が明確になっていないことがわかります。古い本でSQLを学んだという事実は、最初の形式を示し、おそらく役に立たない... ;-)
そして、GoogleでのSQL選択検索で最初に見つけた参照（ほとんどの場合、フランス語の回答が返されます...） ）最初に古い形式を表示します（次に2番目の形式を説明します）。

「なぜ」の質問にいくつかのヒントを与えるだけです... ^ _ ^このトピックについては、優れた最新の本（DB不可知論者）を読む必要があります。誰か提案があれば...

私はすべての学校で話すことはできませんが、私の大学では、コースのSQLモジュールを行っていたときに、ANSI-92を教えていませんでした。古いVAXシステムでANSI-89を教えていました。クエリデザイナを使用していくつかのクエリを構築し、SQLコードを掘り下げてAccessを調べ始めるまで、ANSI-92に触れていませんでした。結合がどのように完了するのか、または構文を理解して理解を深めるために深く掘り下げたことがわからなかったことがわかりました。

多くの場合、利用可能なドキュメントは正確に直感的ではなく、人々は自分が知っていることに固執する傾向があり、多くの場合、仕事を完了するために必要以上のことを学ぼうとはしません。採用に長い時間がかかる理由は簡単にわかります。

もちろん、いじくり回して理解したい技術的伝道者がいます。「新しい」原則を採用し、残りを変換しようとするタイプの傾向があります。

奇妙なことに、多くのプログラマーが学校を出て進歩を止めているようです。これは彼らが教えられたものであるので、これはそれがどのように行われたかであると考えています。目隠しを外すまでは、学校は基本を教えるだけで、残りの部分を自分で習得するための十分な理解を提供することだけを目的としており、実際に知っていることの表面をかすかに引っ掻いたにすぎません。今、その道を続けるのはあなたの仕事です。

もちろん、それは私の経験に基づく私の意見にすぎません。

1）* =または（+）=とは異なり、OUTER JOINを書き込む標準的な方法

2）NATURAL JOIN

3）データベースエンジンによっては、ANSI-92がより最適になる傾向があります。

4）手動最適化：

次の構文（ANSI-89）があるとします。

(1)select * from TABLE_OFFICES to,BIG_TABLE_USERS btu
where to.iduser=tbu.iduser and to.idoffice=1

それは次のように書くことができます：

(2)select * from TABLE_OFFICES to
inner join BIG_TABLE_USERS btu on to.iduser=tbu.iduser
where to.idoffice=1

しかしまた：

(3)select * from TABLE_OFFICES to
inner join BIG_TABLE_USERS btu on to.iduser=tbu.iduser and to.idoffice=1

それらのすべて（1）、（2）、（3）は同じ結果を返しますが、最適化方法は異なります。データベースエンジンによって異なりますが、ほとんどの場合、次のようになります。

• （1）データベースエンジン次第で最適化を決定します。
• （2）両方のテーブルを結合し、オフィスごとにフィルターをかけます。
• （3）idofficeを使用してBIG_TABLE_USERSをフィルターし、両方のテーブルを結合します。

5）クエリが長いほど、煩雑さが少なくなります。

老若男女のプログラマー、研修生、新卒者との私の実際的な経験から人々がANSI-89を使用する理由：

• 彼らは（本ではなく）既存のコードからSQLを学び、コードからANSI-89を学びます
• ANSI-89はタイピングが少ないため
• 彼らはそれについて考えず、どちらか一方のスタイルを使用し、どちらが新しいものか古いものかを知らず、どちらも気にしません
• コードは、コードを保守している次のプログラマーとのコミュニケーションでもあるという考えは存在しません。彼らはコンピュータに話しかけ、コンピュータは気にしないと思っています。
• 「クリーンコーディング」の技術は不明です
• プログラミング言語とSQLの知識が特に乏しいため、他の場所で見つけたものをコピーして貼り付ける
• 個人の好み

私は個人的にANSI-92を好み、ANSI-89構文で表示されるすべてのクエリを変更して、SQLステートメントをよりよく理解することもあります。しかし、私が一緒に仕事をしている人の大多数は、多くのテーブルで結合を作成するのに十分なスキルがないことに気付きました。彼らは可能な限り優れたコーディングを行い、SQLステートメントに初めて遭遇したときに記憶したものを使用します。

ここでは、SQL-89とSQL-92を比較し、他の回答の誤解を解消するためのいくつかのポイントを示します。

1. NATURAL JOINS恐ろしい考えです。これらは暗黙的であり、テーブルに関するメタ情報が必要です。SQL-92については何も必要としないため、無視してください。これらはこの議論には関係ありません。
2. USING 素晴らしいアイデアです。2つの効果があります。
   1. 等結合からの結果セットに1つの列のみを生成します。
   2. それは健全で健全な慣習を強制します。SQL-89ではid、両方のテーブルに列を書き込む人がいました。テーブルを結合した後、これはあいまいになり、明示的なエイリアスが必要になります。さらに、id結合のはほぼ確実に異なるデータを持っていました。あなたが会社に人に参加した場合、あなたは今、エイリアス1に持ってidまでperson_id、1 idにcompany_id2つのあいまいな列を生成する参加されずに、。テーブルのサロゲートキーにグローバルに一意の識別子を使用することは、標準でが得られる規則USINGです。
3. SQL-89構文は暗黙的CROSS JOINです。A CROSS JOINはセットを削減せず、暗黙的に増加させます。はとFROM T1,T2同じFROM T1 CROSS JOIN T2ですが、デカルト結合を生成しますが、これは通常は必要ありません。それを遠くのWHERE条件付きのものに減らす選択性を持つことは、設計中に間違いを犯す可能性が高くなることを意味します。
4. SQL-89 ,とSQL-92の明示的なJOINは、優先順位が異なります。JOIN優先順位が高くなります。さらに悪いことに、MySQLのような一部のデータベースは非常に長い間、これを間違っていました。。したがって、2つのスタイルを混在させることはお勧めできません。今日、はるかに人気のあるスタイルはSQL-92スタイルです。

OracleはANSI-92をまったく実装していません。Oracle Appsのデータテーブルには列が非常に豊富にあるため、いくつかの問題がありました。結合の列数が約1050列を超える場合（これはAppsで非常に簡単です）、論理的に意味のないこの誤ったエラーが発生します。

ORA-01445: cannot select ROWID from a join view without a key-preserved table.

古いスタイルの結合構文を使用するようにクエリを書き直すと、問題が解決します。これは、ANSI-92結合の実装に非難の指を向けているようです。

私がこの問題に遭遇するまで、私はASNI-92の不動のプロモーターでした。これは、古いスタイルの構文では非常に簡単である、偶発的なクロス結合の可能性を減らす利点があるためです。

しかし今、私はそれを主張することははるかに難しいと思います。彼らはOracleの悪い実装を指摘し、「私たちは自分たちのやり方でやります、ありがとう」と言います。

新しいSQL標準は、「互換性の束縛」とも呼ばれる以前の標準からすべてを継承します。したがって、 'old' / 'comma-separated' / 'unqualified'結合スタイルは完全に有効なSQL-92構文です。

さて、SQL-92 NATURAL JOINがあなたが必要とする唯一の結合であると私は主張します。たとえば、inner join重複する列を生成しないため、より優れていると私は主張しています- SELECT列を明確にする句の範囲変数はもうありません！しかし、すべての心を変えることは期待できません。そのため、私が個人的にレガシー結合スタイルであると私が考えるものを採用し続けるコーダーと協力する必要があります（そして範囲変数を「エイリアス」と呼ぶことさえある！）。これはチームワークの性質であり、孤立して動作するわけではありません。

SQL言語の批判の1つは、意味的に同等の構文（リ​​レーショナル代数を使用するもの、リレーショナル計算を使用するもの）を使用して同じ結果を得ることができるということです。 。そのため、私はと同じように「古いスタイル」の結合に快適ですINNER。時間をかけてそれらを書き直すかどうかNATURALは、コンテキストに依存します。