ANSI092 標準にはかなり凶悪な構文が含まれています。自然結合はその 1 つであり、USING 句は別のものです。私見、テーブルへの列の追加はコードを壊すべきではありませんが、NATURAL JOINは最もひどい方法で壊れます。中断する「最善の」方法は、コンパイル エラーによるものです。たとえば、どこかで SELECT * を実行すると、列を追加できます。コンパイルに失敗します。失敗する次善の方法は、実行時エラーです。ユーザーに表示される可能性があるため、さらに悪いことですが、それでも何かが壊れているという素晴らしい警告が表示されます。ANSI92 を使用し、NATURAL 結合を使用してクエリを記述した場合、コンパイル時も実行時も中断されず、クエリは突然間違った結果を生成し始めます。これらのタイプのバグは潜行性です。レポートがうまくいかず、財務開示が正しくない可能性があります。
NATURAL Join に慣れていない方向け。両方のテーブルに存在するすべての列名で 2 つのテーブルを結合します。4 列のキーがあり、それを入力するのにうんざりしている場合、これは本当にクールです。問題は、Table1 に DESCRIPTION という名前の既存の列があり、Table2 に新しい列を追加するときに発生します。名前はわかりませんが、うーん、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
これは完全にあいまいです。Company テーブルと user テーブルの両方に UserID 列を配置しましたが、何の不満もありません。company の UserID 列が、その行を最後に変更した人の ID である場合はどうなるでしょうか?
私は真剣です、なぜそのような曖昧さが必要だったのか誰か説明できますか? なぜ標準にそのまま組み込まれているのですか?
コーディングを通じてそこにコピー/ペーストする開発者の大規模なベースがあるというビルの意見は正しいと思います。実際、ANSI-92 に関して言えば、私は一種の人間であることを認めます。私がこれまでに見たすべての例では、複数の結合が括弧でネストされていることが示されていました。正直なところ、それはせいぜいSQLでテーブルを選択することを困難にします. しかしその後、SQL92 の伝道者は、実際には結合順序が強制されると説明しました。JESUS ... 私が見たすべてのコピー貼り付け作業者は、現在、実際に結合順序を強制しています。これは、95% の確率でオプティマイザー、特にコピー/貼り付け作業者に任せたほうがよい仕事です。
彼が言ったとき、トマラクはそれを正しく理解しました、
新しい構文があるからといって、新しい構文に切り替えることはありません。
それは私に何かを与えなければならず、私は利点を見ていません。そして、プラス面がある場合、マイナス面は無視するには大きすぎるアホウドリです.