形式的に構造化されたほぼすべての情報セットでは、最初から最後まで、または場合によっては最後から最初に向かって読み始めます (住所など)。しかし、SQL、特に SELECT クエリでは、適切に理解するためにその意味は、FROM 句の途中から開始する必要があります。これにより、特にネストされた SELECT クエリが含まれている場合、長いクエリが非常に読みにくくなる可能性があります。
通常、プログラミングで何かが意味をなさないと思われる場合、その背後には歴史的な理由があります。FROM の代わりに SELECT で始めるのは意味がありません。それがそのように行われる理由を誰かが知っていますか？
英語の文が構造化されている限り、SQL ステートメントが構造化される方法は論理的に理にかなっていると思います。基本的
I WANT THIS
FROM HERE
WHERE WHAT I WANT MEETS THESE CRITERIA
少なくとも英語で言うのはあまり意味がないと思います
FROM HERE
I WANT THIS
WHERE WHAT I WANT MEETS THESE CRITERIA
SQL ウィキペディアのエントリには、いくつかの歴史が簡単に説明されています。
1970 年代、IBM サンノゼ研究所のグループは、Edgar F. Codd が影響力のある論文「A Relational Model of Data for Large Shared Data Banks」で紹介したモデルに基づいて、System R リレーショナル データベース管理システムを開発しました。その後、IBM の Donald D. Chamberlin と Raymond F. Boyce は、System R に格納されたデータを操作および管理するためのStructured English Query Language (SEQUEL)を作成しました。「SEQUEL」は英国の商標であったため、頭字語 SEQUEL は後に SQL に変更されました。本拠地ホーカー・シドレーの航空機会社。
元の名前は明示的にEnglishに言及し、構文を説明していました。
もう少し深く掘り下げると、FLOW-MATICプログラミング言語が見つかります。
元々は B-0 (ビジネス言語バージョン 0) として知られていた FLOW-MATICは、おそらく最初の英語に似たデータ処理言語です。これは Grace Hopper によって発明され仕様が定められ、1955 年に UNIVAC I 用に Remington Rand で商用バージョンの開発が開始されました。
FLOW-MATIC は、現在も使用されている最も古いプログラミング言語の 1 つであるCommon Business Oriented Languageの背後にあるインスピレーションでした。その精神を保ちながら、SEQUELは英語のような構文で設計されました (1950 年代と 1960 年代に比べて 1970 年代は現代的です)。
概観すると、「最新の」プログラミング システムは依然として、背後にある古いアイデアを使用してデータベースにアクセスします。
MULTIPLY PRICE BY QUANTITY GIVING COST.
私は反対しなければなりません。SQL 文法は裏返しではありません。
一見しただけで、クエリがデータを SELECT、INSERT、UPDATE、または DELETE するかどうかがわかります (DDL などの残りの SQL はすべて意図的に省略されています)。
SELECT ステートメントの混乱に戻ります。SQL の目的は宣言型であることです。つまり、どのように望むかではなく、何を望むかを表現するということです。したがって、最初にWHAT YOU WANT (選択している属性のリスト) を記述し、次に、どこから検索する必要があるかについての追加情報を DBMS に提供することは、あらゆる意味を持ちます。
最後に WHERE 句を配置することも非常に理にかなっています。上部が広く、下部が狭いじょうごを想像してみてください。ステートメントの最後に WHERE 句を追加すると、結果のデータの量が減ります。下部以外の場所でクエリに制限を適用すると、開発者は頭をひっくり返す必要があります。
最後に ORDER BY 句: データがじょうごを通過したら、並べ替えます。
JOINS (JOIN 条件) は実際には FROM 句に属します。
グループ化: 基本的に、別のファネルに入る前にデータをファネルに通します。
SQL構文は甘いです。それについて裏返しは何もありません。おそらくそれが、何十年も経った今でもSQLが非常に人気がある理由です。把握して意味をなすのはかなり簡単です。(7 ページ (A4 サイズ) の SQL ステートメントに直面したことがあり、理解するのにかなりの時間がかかりました。)
英語のように設計されています。それが一番の理由だと思います。
ちなみに、LINQ の最初のプレビューは、LINQ を直接モデルにしたものだったことを覚えています ( select ... from ...)。これは、後のプレビューで、よりプログラミング言語に似たものになるように変更されました (スコープが下方に行くように)。Anders Hejlsberg は、この決定を行った理由として、SQL に関するこの奇妙な事実 (IntelliSense を難しくし、C# のスコープ ルールと一致しない) について具体的に言及しました。
とにかく、良くも悪くも、それが現状であり、何かを変えるには遅すぎます.
SQL の句の順序は完全に論理的です。SQL は宣言型言語であることを思い出してください。ユーザーが必要なものを宣言すると、システムがそれを取得する最善の方法を見つけ出します。最初の節は、結果表に必要な列をリストする select 節です。これがクエリの主な目的です。結果をどのように見せたいかを述べたら、次にデータがどこから来るべきかを述べます。where 句は、返されるデータの量を制限します。データがどこから来たのか分からない限り、データを制限する方法を考えても意味がないので、from 節の後に置きます。group by 句は、select 句の集計演算子と連携し、from 句の後の任意の場所に移動できますが、フィルタリングされたデータの集計について考える方がよいため、where 句の後に配置します。having 句は、group by 句の後に来る必要があります。order by 句は、データがどのように表示されるかに関するものであり、select の後にどこにでも行くことができます。
言語の歴史はさておき (魅力的ではありますが) あなたが見逃しているのは、SQL はシステムに何をすべきかを伝えることではなく、どのような最終結果を望むか (そしてそれを行う方法を理解すること) であると思います。
「あそこのラックに行って、帽子バンドのついた帽子を手に取り、最初に青い帽子、次に緑、次に赤の帽子を持ってきて、それを私のところに持ってきてください」と言うのは、あなたが望むことをどのように行うかをシステムに非常に伝えています. ワーカーが非常に愚かで、詳細な指示が必要であると私たちが推測するのは、プログラマーだと思います。
SQL は、最初に最終結果、必要なデータ、列の順序などから始めます。これは、レポートを作成している人の視点です。「ファーストネーム、ラストネーム、そして年齢、それから……」それがリクエストの目的です。それで、それはあなたが望む結果のフォーマットから始まります。次に、データを見つけると予想される場所、探す基準、データを表示する順序などに進みます。
そのため、ワーカーに何をしてもらいたいかを詳細に指定する代わりに、SQL はシステムがそれを行う方法を知っていると想定し、ユーザーが望むことに重点を置きます。
だから、従業員にここに行って、これを持ってきて、そこに持ってくるようにペテンに言う代わりに.. 「12 ラックから、帽子バンドが付いている帽子が欲しいので、色で分類してください」と言っているようなものです。
CREATEこれは、すべてのステートメントを動詞 ( 、DROP、UPDATEなど)で開始するという SQL の残りの構文と一致しています。
列リストを最初に持つことの主な欠点は、(Hejlsberg が述べたように) オートコンプリートにとって不便であることですが、1970 年代に構文が設計されたとき、これは問題ではありませんでした。
のような構文で両方の長所を活かすことができたかもしれませんが、SELECT FROM SomeTable: ColumnA, ColumnB今それを変更するには遅すぎます。
とにかく、SQL のSELECTステートメントの順序は一意ではありません。Python のリスト内包表記と完全に一致します。
[(rec.a, rec.b) for rec in data where rec.a > 0]