日本では、エスキューエルと読むけど、スィーケルらしい。
先月の商品別の出荷状況は
Select G.商品名, G.スペック, G.単価, T.個数
From GOODS G
Left Join Ticket T On G.jan_code=T.jan_code
Left Join Customer C On T.custom_code=C.code
Where T.timestamp Between TO_DATE(‘2013/01/01′, ’yyyy/mm/dd’) AND TO_DATE(‘2013/02/01′, ’yyyy/mm/dd’) - 1 days
のように英文っぽく書く。
大雑把には、
Select句 は表示したい項目を指定する
from句は使用するテーブルを指定する
Join句 はテーブル間のデータの関連付けを指定する
where句はfrom句で指定したテーブルのデータを絞り込む
な感じで大雑把に欲しいデータをダウンロードするのに向いている。
昔からあったデータベース言語は
特許文書検索などデータベース構造に依存したもので汎用的なものではなく
qABCnDEFaGHI とか※適当
と可読性皆無な余りにも酷い代物しかなかったのでSQLがウケた。
※実装はawkみたいなだったのかもしれない。
しかし、実のところ何ができるかと云えば中学校あたりで教える集合の概念＋グルーピング程度で
レポートなどで良く使うキーブレークがあるからEXCELよりマシな気もするが、
SQLには無い概念ものはたとえ中学生で教えるクラス分類すらできない。
Group By 句でデータの分類は可能だが、あくまでも種別コード毎の分類で、
10～19、20～29、30～39、40～49、50～59・・・
な分類ならINT(Age/10)の値を用いて分類しなければいけない。
だが、ほどんどのRDB（リレーショナルデータベース）は
インデックス（重複しない任意の整数）でデータを分類する方法が推奨されている
大方のデータベースではレコードの統計情報からインデックスのB-Tree構造を都合よく手直しし、
滅多に使わないレコードは管理情報すら触らない様にして見かけ上の性能アップを行っている。
例えば、Where Age < 20 なら
B-Treeの木構造からAge>=20 以上の情報を見つけその先の枝葉ゴトばっさりと切り捨てることができる。
しかし演算式にそのまま当てはめると、
Where – Age < -20
などは＜演算子だけで判定すると必要なインデックスの方をばっさり捨ててしまうので
Ageの符号演算子も考慮すればよいが
Where ABS( – Age ＋5） < 5
になると、木構造の不要な部分をばっさりと切り捨てることはできない。
そんな訳でGrouo Byに演算式を使った場合は、HDDから全レコードを読むようになっており、レコードが多いほど普段の性能より何桁も下がることになる。
それを防ぐには
Select … From （Select * From Where 年度内) Group By INT(Age/10)
のように事前にデータを絞り込んだ後に GroupBy を使えばかなり性能はUPする。
※一般に（・・・）はビューイングと云われ、ビューイングにネーミングしたものがビューである。ビューを使うと遅いと云われているが、（Select * From Where 年度内)程度で処理が遅くなるハズもなく、Group By INT(Age/10) の部分が遅いだけなのだ。
ここまで読めば、真にデータベースに必要なものはグリッドでもINTELの高性能CPUでもなくGPU（コアの数の暴力）であることが何となく理解できるだろう。
