2009-06-06 4 views
7

正式に構造化された情報の集合では、始めから終わりに向かって、時には末尾から始めに向かって読み始めます(たとえば、住所など)。しかし、SQLでは、特にSELECTクエリは、途中でFROM句で始めなければならないという意味を正しく理解しています。これにより、特にネストされたSELECTクエリが含まれていると、長いクエリを読みにくくすることができます。なぜSQLの文法は裏返しですか?

通常、プログラミングで何かが意味をなさないように見える場合、その背後には歴史的な理由があります。 FROMではなくSELECTで始めることは意味をなさない。誰もがそのようにした理由を知っていますか?

+1

この質問は誤った前提に基づいていると思いますが、回答は面白いです。 – RedFilter

+0

あなたが通りの住所を書く方法は、文化によって異なります。 – tuinstoel

+0

私はアメリカモデルを指していました。あなたが誰かを見つけたいと思っている場合は、アドレスの最後に配置する必要がある情報があります。 –

答えて

9

言って、非常に理にかなっているとは思わない:1970年代

を、 IBM San Jose Research Laboratoryのグループは、Edgar F. Coddによって影響を受けた論文「大規模共有データ・バンクのデータの関係モデル」に導入されたモデルに基づいて、System Rリレーショナル・データベース管理システムを開発しました。 IBMのDonald D. ChamberlinとRaymond F. Boyceはその後、System Rに格納されたデータを操作して管理するためにStructured English Query Language(SEQUEL)を作成しました。 "SEQUEL"は後にSQLに変更されました。英国のHawker Siddeley航空会社。

元の名前は、構文を説明している英語を明示しました。

少し深く掘り下げて、FLOW-MATICプログラミング言語が見つかりました。元々B-0(ビジネス言語バージョン0)として知られている

FLOW-MATIC、は、おそらく最初の英語のようなデータ処理言語あります。それはGrace Hopperによって発明され、指定され、1955年にUNIVAC IのためにRemington Randで開発されました。1958年までに、コンパイラとそのドキュメントは一般に入手可能であり、商業的に使用されていました。

フローメイクは、最もアクティブなプログラミング言語の1つであるCommon Business Oriented Languageの後ろにインスピレーションを与えました。その精神を維持しながら、SEQUELは、英語のような構文(1950年代と1960年代と比べて、1970年代は現代的です)で設計されました。パースペクティブで

は、「現代の」プログラミング・システムは、まだ私は同意しなければならない

MULTIPLY PRICE BY QUANTITY GIVING COST. 
+0

良いキャッチ - 元の頭字語に「英語」という言葉があることを思い出しました。 –

+0

履歴パースペクティブを追加しました。 – gimel

5

英語のように設計されています。私はこれが主な理由だと思う。

補足として、LINQの最初のプレビューは、(select ... from ...)の直後にモデル化されていたことを覚えています。これは後のプレビューで、よりプログラミング言語のように変更されました(スコープが下に行くように)。 Anders Hejlsbergは、この決定を下した理由として、IntelliSenseをより困難にし、C#のスコープルールに一致しないSQLに関するこの奇妙な事実を特に指摘しました。

とにかく、良いか悪いか、それは何ですか、何かを変更するには遅すぎます。

+0

これはLINQの発明ではありません。 LINQのデザイナーは、XQueryの影響を明示的に認めていると思います。私はXQueryを正しい順序で配置する最初の「SQL-cousin」と考えています。 LINQはXQueryをコピーしました。結局のところ、LINQは "SQLのC#"ではなく、 "ほとんどのプログラマーにはよく知られている構文を持つC#のHaskellクエリMonad"です。 –

+0

はい。私はAndersがSQLでスコープの奇妙さを指定したと言いました。 SQLの影響を受けたのは当初でした。当時から根本的に変わってきました。 –

11

英語の文章が構造化されている限り、SQL文がどのように構造化されているかは、論理的に意味があると思います。基本的には

I WANT THIS 
FROM HERE 
WHERE WHAT I WANT MEETS THESE CRITERIA 

は、私はそれが英語では、少なくとも、SQL Wikipedia entry簡単にはいくつかの歴史について説明し

FROM HERE 
I WANT THIS 
WHERE WHAT I WANT MEETS THESE CRITERIA 
+1

これは簡単な文章で意味があります。しかし、クエリが100行で、10個の結合と2個のサブ選択では、 "英語のように見えます"というアプローチは、実際のセンスを素早く停止します。 –

+2

一方、「棚に行って、帽子ですべての帽子を手に入れよう」と言うのは意味があります。これは「FROM rack SELECT hat where has_hatband = 1」です。 「帽子から帽子を持っている帽子からすべての帽子を持ってきてください」と言うこともできます。これは「SELECT HAT FROM RACK WHERE has_hatband = 1」です。これは通常のSQLです。 – JasonFruit

+3

@メイソン - 英語の100行もすぐに複雑になることがありますし、langugageの設計のための有用なモデルではありません:)私は目標が入り口の障壁を下げることだと思います。それは私のために働いた:私が最初にSELECT * FROM MyTableを学んだとき、私は "SQLは簡単だ"と思った。ああ、どれほど素朴だった... – RedFilter

8

の後ろに古い時代のアイデアを使用してデータベースにアクセスします。 SQL文法は裏返しではありません。

非常に最初の外観から、クエリがSELECT、INSERT、UPDATE、またはDELETEのデータ(SQLの残りすべて(例:DDL)は意図的に省略されているかどうか)を判断できます。


戻るSELECT文の混乱へ:SQLの目的は、宣言型になることです。つまり、あなたが望むものを表現し、それを望む方法は表現しません。 最初にの状態になります(属性のリストはです)。には、どこから参照する必要があるかに関する情報が追加されています。

最後にWHERE句を配置することもまた理にかなっています。上部が広く、下部が狭い漏斗を想像してみましょう。文の最後にWHERE句を追加すると、結果のデータの量が減少します。クエリーに制約を適用するには、開発者が頭を下げる必要があります。


最後のORDER BY句:データがファンネルを通過したら、それを並べ替えます。

JOINS(JOIN基準)は実際にFROM句に属します。

GROUPING:基本的に、別のファンネルに入る前にデータをファンネルで実行しています。

SQL sytaxは甘いです。そこには何もない。たぶんSQLは、何十年ものあいだでも非常に人気があります。把握して理解しやすいです。 (以前はA4サイズの7ページのSQLステートメントに直面していましたが、私の頭の中にはかなりの時間がかかりました)

+2

?私は1週間に1〜2回そのような質問に直面します。それに対する絶え間ない曝露は、この質問に私を導いたものです。 –

1

これは、すべてのステートメントを動詞で始めるという残りのSQLの構文(CREATE,DROP,UPDATEなど)。

最初に列リストを作成することの主な欠点は、自動完成(Hejlsbergが述べたように)には不便だということですが、1970年代に構文が設計されたときにはこれは問題になりませんでした。

SELECT FROM SomeTable: ColumnA, ColumnBのような構文で、両方の世界の中で最高のものを持っていた可能性がありますが、それを変更するには遅すぎます。

とにかく、SQLのSELECTステートメントの順序は一意ではありません。 SQLでの句の順序は絶対に論理的である

[(rec.a, rec.b) for rec in data where rec.a > 0]

2

:それはまさに、Pythonのリスト内包のことを一致します。 SQLは宣言型言語であり、あなたが望むものを宣言すると、システムはそれをどのように入手するのが最適かを判断します。最初の句は、結果表に必要な列をリストするselect句です。これがクエリの主な目的です。結果をどのように見せたいかを述べた上で、次にデータがどこから来るべきかを述べます。 where句は、返されるデータの量を制限します。どこから来たのか分からない限り、データをどのように制限するかについて考えているわけではないので、from節の後に来ます。 group by節はselect句の集約演算子で動作し、from句の後ろのどこにでも置くことができますが、フィルタ処理されたデータの集約について考えてみると良いでしょう。 having節はgroup by節の後に来なければなりません。 order by節は、データがどのように表示され、選択後にどこに行くことができるかに関するものです。

1

言語の歴史(魅力的ですが)私は、あなたが欠けていることは、SQLがシステムに何をすべきかを伝えることではなく、どのような最終結果を望んでいるかということです

は非常にどのようににシステムを言っている「は赤、最初に、そして緑、青の帽子をhatbandsと帽子を拾う、と私にそれらをもたらす、そのラックにあそこ行く」と言って)それを行うにはあなたが望むことをやりなさい。それはプログラマだと思う私たちは、非常に愚かで細かい詳細な指示を必要とすると思います。

SQLは、最初に最終結果、必要なデータ、列の順番などから始めます。レポートを作成している人の視点です。 "私は姓、姓、年齢、その後....."を要求します。これはリクエストを行うすべての目的の後です。それでは、あなたが望む結果のフォーマットから始まります。次に、データを検索するための基準、探したい基準、提示する順序などが表示されます。

従業員に何をしたいかを細かく指定する代わりに、SQLは、システムはそれを行う方法を知っていて、あなたが望むものをさらに集中させます。

ここに行くように作業員に指示するのではなく、これを持ってきてください。「もっと帽子が必要です」と帽子が付いている棚12から帽子が必要です。

関連する問題