SQLとはどんな言語か - SQLは仕様書です

SQLとはどんな言語かなぜ多くの人が違和感を持つかというと、多くの人が、「プログラミング言語とは手続き型言語である」（オブジェクト指向言語も広義の手続き型言語）という思い込みがあるからでしょう。

　手続き型言語の中には
　　　非構造化言語（FORTRANなど）
　　　構造化言語（C言語など）
　　　オブジェクト指向言語（Javaなど）

　などなどがあり、SQLを除けば、数十年前から現在に至るまで、手続き型言語のシェアは95％を超えるのではないでしょうか。関数型言語などは現場で見ることはほとんどありません。ですから、「プログラミング言語とは手続き型言語である」と思っても仕方がない。

　SQLは多くの手続き型言語とは性質を異にするものです。「プログラミング言語とは手続き型言語である」と仮定すれば「SQLは仕様書である」と言えます。

　SQLとは、その前進の名前 SEQUEL (Structured English Query Language)が示すとおり、英語を目指して作られています。余談ですが、名前の由来が SEQUEL であるため、英語圏の方は未だにSQLを"シークェル"と発音される方が多くいます。（詳しくは wikipedia がよくまとまっていますのでご覧ください。 http://ja.wikipedia.org/wiki/SQL）

　関係代数と関係論理に基づいているかいないかは全く関係ない。理論に基づいていたら習得し易いというものでも、効率的であるというわけでもないし、理論に基づかないから使えないということもありません。そもそも、英語に近づけたいという思想の方が強かったわけです。

　目的は、自分が欲しい結果を得るためにアルゴリズム（手続き処理）を作ることができない、つまり、技術者ではない事務員でも書けるように英語に近づけることで、英語に近づけるための手段として関係代数と関係論理を利用しただけですから、目的と手段をはき違えたクリス・デイト、ヒュー・ダーウェンなどの批判など的外れもいいところです。

　英語ですから、SELECT・UPDATE・INSERT・DELETE という動詞の現在形から始まる命令文になっているわけですが、処理から考えるとSELECT句などは一番最後に実行されます。この英語に似せるというコンセプトが、「プログラミング言語とは手続き型言語である」と考える技術者にとって分かりにくいものになっている最大の原因だと私は考えています。

　処理を考えてしまう技術者にとっては処理順に書くLINQの語順の方がしっくり来るでしょう。私も自分がSQLを企画するとしたらLINQの語順で作ったでしょう。LEFT OUTER JOIN なんて長ったらしい記述は避けて、何らかの演算子となる記号で表現する様にしたでしょう。

　しかし、語順・記述法がどうあれ、一定のルールで記述するのであれば慣れてしまえば大差はありません。SQLは構造化問合せ言語と呼ばれるとおり、構造化された「句」毎に分けて実行されます。ただし、FROM句・WHERE句は同時に（混ざって）実行されます。

　これは追々詳しく書いていきますが、「句」毎に書けばいいし「句」毎に見ていけば読めます。

　私はSQLの書き方について文法解説をほとんどしません。それは文法解説は入門書からリファレンスまでたくさん出ているからということもありますが、そもそも、SQLが魔法か呪文と考えているかのように、SQLと処理が繋がってない人が余りに多いからです。それはSQLが当初目指したとおりである意味正しいし、確かに、簡単なものであれば文法さえ分かっていればある程度書けます。

　しかし、その感覚で作られたものはプロが納めるものとしてはレベルが低すぎる。ですから、あくまでも処理から考える方法を伝えていきたいと考えております。

　繰り返しですが、「プログラミング言語とは手続き型言語である」とするならば、「SQLは仕様書である」のです。

　SQLという仕様書からプログラムを作成するのはオプティマイザというプログラムです。オプティマイザは人間と違って杓子定規にしかプログラミングはできません。そのオプティマイザという杓子定規で出来の悪いプログラマにどう説明するか。そういう視点で見れば良いSQLが書けます。「プログラミング言語とは手続き型言語である」という感覚を持っていたとしても違和感を持つこともないでしょう。

　オプティマイザというプログラマは、アルゴリズムが書かれていないSQLという仕様書から「実行計画」というアルゴリズム（プログラム＝実行計画）を考えます。しかし、SQLという仕様書で、余程正確な指示を出してやらないとよい「実行計画」というプログラムは出てきません。

　オプティマイザは年々賢くなってはいますが、仕様書を書く技術者としてオプティマイザに頼るのではなく、どうすればオプティマイザが理解しやすいか考えて「SQLという仕様書」を書かないといけませんし、当然、できあがった「実行計画」というプログラムは正しいかレビューする必要があるわけです。

　とにかくSQLは仕様書です。そういったことを今後も書いていきたいと思います。