SQLの苦手を克服する本：読んだ感想
SQLの苦手を克服する本 (Amazon リンク)by 生島 勘富 & 開米 瑞浩 を読みました。
感想と自分的に面白いと思ったポイントを3点ピックアップします。
SQL入門的な書籍を期待してましたが、実際はSQLの苦手の克服にはならなかったけれど、SQLを使う現場での話を例にDBの仕組みを紹介してくれている本です。DB設計の本かというとそうでもない。
SQL苦手は克服できていないが、読んでいてSQLの重要性と仕組みに対して知識は増えて面白かったです。
処理は出来るだけSQLで済ませる
必要なデータだけSQLから取ってくる。
アプリ側で一旦取って処理をするより、SQLはただのデータベースとして使うだけでなく効率良くデータを取る方がいい。
私はそもそもDBはなるべくたたかない物という誤った認識を持っていました。
前に関わった事のあるプロジェクトもデータをドカンと取ってフロントで制御していました。ループ処理などいろんなところで多用してしまい、リリース状態から少しモッサリしていてユーザーに対して使いづらいシステムになっていました。
DBからデータ取得する際にフロントエンドでデータを加工する必要がない取り方をした方が良い。
ループ使うな
アプリ側でSQLを複数回発行してしまうケースだとその分DBを叩いて処理速度が落ちて、コストが上がってしまう。
処理をSQL側で書くと、一時的にスパイクするが結局はループした方が負荷が総合的にかかる。
本の中の例えでお弁当屋さんの話がしっくり来たので紹介します。A弁当とB弁当のオーダーを10件ずつ受けた場合、アプリ側は一気にオーダーをキッチン（サーバー）に渡すのが一般的な考えですが、プログラムだと処理によってはA弁当とオーダーしてからB弁当のオーダーを渡すとか一個づつ処理を書いてしまったり、パーツを頼んでアプリの方で組み立てたりしてしまうケースが用意に想像できました。だから出来るだけ一括でSQLで処理した方がいいとのことです。
Joinの使い方 と IN と Existの処理の違い
作者いわく、SQLの複雑性やスケールアウトしてデータベースが分散する事を懸念して、Joinを使わない決まりがある会社がかなりあると。
INとExistのどちらかを使うべきかは主表と従属表にどちらに選択性が高いか使い分ける事で処理速度が違う。
本の例えですと1990年以降で発売されて、販売数30万以上売れて、テーマが失恋であるデータを検索する場合、一番絞れるデータが主表に所属している販売数なので、この場合Existを使った方が良い。
| 条件 | 表 | 選択性 | 比率 |
|---|---|---|---|
| 1990年以降発売 | 主表(songs) | 低 | 50% |
| 販売数30万以上 | 主表 (songs) | 高 | <1% |
| テーマが失恋 | 従属表 (attr) | 低 | 80% |
SELECT * FROM songs s
WHERE s.published_year > 1990
AND s.sales_count > 300000
AND EXISTS (
SELECT 1 FROM attr a
WHERE
s.id = a.s_id
AND theme <> "失恋"
);INを使うケースだと例えば自分の関わったプロジェクトで、1950年以降で発表されたレアな食材なレシピで検索する場合、例えばカンガルーの肉を取り扱っている物は従属表で絞り込めやすそうです。
| 条件 | 表 | 選択性 | 比率 |
|---|---|---|---|
| published_year after 1950 | 主表(レシピ) | 低 | 90% |
| カンガルー | 従属表 (食材) | 高 | <1% |
SELECT * FROM recipes r
WHERE id IN (
SELECT r_id FROM ingredients where ingredient_name = "kangaroo"
)
AND r.published_year > 1950;以上が面白いと思った3点のピックアップです。
ちゃんと勉強するには別の本が必要ですが、効率良いクエリの書き方が大事という事が分かり、知見が無いビギナーでも読める本でした。
