ハッピバースデートゥミ〜〜〜♪ハッピバースデートゥミ〜〜〜♪、ハッピバースデーディアわたし〜♪
ハッピバースデートゥミ〜〜〜♪
がく＠ちゅらデータ（49）です。
夏休みで子らが家にずっといたので、そちらで体力と時間を持っていかれたので、全然かけておりませんでした・・・
※そして、下書きにしたまま、なぜかアドベントカレンダーの季節になっていた・・・orz
ちょっと溜まっているネタがあるので、ぼちぼち書いていこうと思います
さて、時間はないのに、面白そうな本ばかりでて、ゴンゴン買ってしまう・・・
そう、積み本（罪本）がどんどんたまっていってしまうのです。ですので、そちらを解消（せめて、一読する）をしようと思います！
そこで、第一弾はミックさん著「達人に学ぶSQL徹底指南書第2版」です。
大きく2章に分かれています
- 魔法のSQL
- リレーショナルデータベースの世界
魔法のSQL
さすが、「初級者→中級者になるため」の徹底指南書ですので、一般的なSQL文の書き方というのではなく、より深いお話ばかりでてきます。
- CASE式
- 3値論理とNULL
- ウィンドウ関数
- EXISTS句やHAVING句の威力
- 早くするぞー
- SQLの書き方その流派、宗教戦争を超えて
単にリファレンスでSQLの句を知っていただけでは学べないことばかりで、分析の業務などでSQLを書く人は必読の章です！
まじ読みましょう！
リレーショナルデータベースの世界
で、1章は以前に何度も何度も読んだので、今回の「積読解消」では、2章のこちらをよんでいこうかなっと思ってます。
（1章読みたい人は、ぜひ買って読んだらいいと思います！なんなら勉強会やハンズオンやってもいいのだけど）
RDB近代史
データベースに破壊的イノベーションは2度起こるか！？
って話が面白いです。
まず、1つ目の破壊的イノベーションは、「リレーショナルデータベース」の出現
2つ目の破壊的イノベーションにはいまのところなっていない「NoSQL」
RDBは、その汎用性の高さから、ほぼITエンジニアにとって、空気や水のように当たり前のインフラのようなものになってますよね。でもそれがなかった時代もあったわけです
そんなデータベースの歴史を丁寧に記載されています。
- RDB以前
- リレーショナルデータベースの時代
- RDBの限界とNoSQLの登場
RDBは直感的でわかりやすいデータモデルとSQLというユーザが使いやすいインターフェース言語が破壊的イノベーションをお越し、データベースのメインストリームの座を
※RDB以前は、階層型DBがメインストリームはってました
課題1 性能と信頼性のトレードオフ
RDBはボトルネックになりやすい原因は
- ストレージがシングルボトルネックポイントになってスケールしにくい
- SQLが柔軟で強力が故に、かえって複雑な処理をやれてしまう
- がゆえに、DBに処理を任せてしまいすぎて、そこがボトルネックとなる
- ※スケールアウトやスケールアップをどうするか、コンピュートをどこにさせるか？あたりは、本と場合によってプロダクトを考えなければね
データモデルの限界
基本的「テーブル」形式
グラフ、非構造化のデータモデルが苦手
そのRDBの課題の対応は二通り
- RDBの機能を高度化することで対応
- RDB以外のデータベースを利用
NoSQLの登場
パフォーマンスの問題を解決するには
- データモデルを単純化し、複雑なデータ操作を制限する（ACIDを捨てる）
- シングルボトルネックポイントをなくしてスケールアウトを可能にする
→ 要は超巨大な連想（ハッシュ）配列
そして最後に、NoSQLはRDBに取って代わるか？という議論で締めくくられています。詳しくは本読んでくださいね♪
なぜ”関係”モデルという名前なのか？
なぜ、”表”モデルではないのか？
関係と表はよく似ているが違うもの
- 関係の組は上下の順序は関係ないけど、表だと関係する
- 関係の属性は左から右に順序は関係ないけど、表は関係する
- その他にも結構ある ※ここは本を読んでね
関係に始まり関係に終わる
- 閉包性
- 演算子の入力と出力が関係になる
- 関係 → 関係演算子 → 関係
- selectの結果（集合）が、次のselectの入力（集合）になる
- UNIXのパイプの概念によく似ている
- 様々なコマンドに対して入力・出力が閉包性
- ファイル → シェルコマンド → ファイル
- cat hoge | grep aaaa | tail みたいに、コマンドの結果が次のコマンドの入力になる
アドレス、この巨大な怪物
- なぜRDBにはポインタがないのか？
- そもそも、RDBはアドレスを意識しないように「見えるように」作った
- 標準SQLは、注意深くポインタを排除するように作っている
- SQLは基本的な設計思想に「アドレスからの開放」、手続き型言語脳だと気持ち悪い・・・と感じる一端
- アドレスを意識しなくていい・・・は、関数型言語（LispとかHaskillとかScala）に類似している
- 私は関数型言語の再帰関数の考え方がすごい衝撃的で、SQLに通じるものがなんかあるなぁと感じています
順序を巡る冒険
- 本書の主役は、ウィンドウ関数
- ウィンドウ関数はまじすごい
- ウィンドウ関数は遅れてきた主役
- なぜウィンドウ関数が遅れたかといえば、SQLは基本的に「順序」は考慮しない、アドレスは意識しない、ってポリシーがあったので、導入の決断がなかなかできなかった（？）
- 「SQLの行には順序は持たない、いや持つべきではない！」との考えがあった
- ウィンドウ関数は、OLAP（分析の用途）で必要な「移動平均、累積、ランキングやパーセンタイル、リードやラグ」が存在しない！ ってのがあり、入れざるを得なくなっていった
GROUP BY と PARTITION BY
- グループ分けの機能を持つ似た者同士の句
- 違いは、GROUP BY は分割した後に集約して一行にまとめる操作が入ることだけ
手続き型から宣言型・集合指向へ頭を切り替える7か条
最近やっとSQL脳になってきたかな・・・とは思うのですが、長年慣れ親しんできた手続き型言語（C言語、Perl、Java、Python）的な考え方（forとか特に）から集合言語的な考え方にするのはすごく大変でした
また、弊社でも新人研修で、SQL研修をやってますが、他のPython研修とかより、違う脳を使うのか疲弊度が段違いな感じがしましたｗ
- 行には「順序」はない
- ループは、GROUP BYとウインドウ関数で代用できる
- EXISTS句の「量化」はすごい概念
- HAVING句は、SQLの集合指向言語としてのエッセンスが詰め込まれている
- SQLはベン図で考える
神のいない論理
3値論理（true, false, unknown(null))が全ての元凶（？）
古典論理学＝神の論理 ってことで、真か偽のみ、「分からない」って状態ってあるけど、全知全能の神様には、「真偽」のみで、「分からない」なんてことはない！ って古典
論理学の推移みたいなものも書いてて、とても思索的というか、そんな章
SQLと再帰集合
順序数やノイマンによる自然数の帰納的定義 とかむずかしーーーー話がでますが、数学的な知識があるとめちゃ面白いです
まず0を定義して・・・・って、弊社の「数学の神」が同じことをYoutubeにあげてましたｗｗｗｗｗｗ
※これが元ネタだったのか・・・・さすがくれいじーな弊社新卒ｗ
NULL撲滅委員会
NULLの悪いところが列挙 されてますｗｗｗｗｗｗｗｗ
すでに1章の「3値論理とNULL」でも記載があったのですが、何度も声を出してよむべき章ですｗ
「NULLは薬だと思ってほしい。正しく使っている限りは有用だが、乱用すれば全てをぶち壊す（以下略）」
まとめ
ミックさん著「達人に学ぶSQL徹底指南書第2版」はまじデータを扱う人は必読の書です。
何度も何度も読み返すべき名著です！！！！（1章だけでも・・・）
ほんといい本をありがとうです！
Discussion