「失敗から学ぶRDBの正しい歩き方」を読んで見たけどめちゃ勉強になる本だった

f:id:suganoo:20190321235453j:plain

こんにちは suganoo です。

今回は「失敗から学ぶRDBの正しい歩き方」を読んで見ました。

たまたま会社の上長が注文してて本棚にあったので手にとって見たんですが.............

めちゃめちゃ面白くて勉強になりました！！！

これは当たりですよ！読みやすい！

あんまり自分はDBの運用管理やアプリケーションを作った経験がないんですが、情報処理試験のDBを何度か受けてたんではまるポイントはいくつか知ってましたがこれはそれ以上に網羅されているなと思いました。

内容

内容は全20章になっていて、1章ごとにDBのアンチパターンが紹介されていて、それに対する原因と対策が説明されています。

そのアンチパターンが具体例を持って説明してくれているんですが、
「あーこれよくやりそうだわ！」と思わずいいたくなるケースが多いんです。

いろいろアンチパターンのケースを紹介するんですが、どれも背筋が凍りそうでぞくっとするアンチパターンが多いです。

例えば「フラグの闇」というケースでは、
会員の削除機能のために会員テーブルから物理的に直接削除してしまうと、やっぱり元に戻したいという要望に応えられない。
なので会員テーブルに"削除フラグ"をつけました、というケース。

そのおかげで有効な会員を抽出したいケースが多いのに、毎回のSQLで"削除フラグ"にチェックなしの条件を入れなければならず、さらにJOINする時も条件が増えてSQLが複雑になってしまうようです。

あー、これオレもやりそうだなと思いました。

そういう時は削除済みテーブルを別途作るか、有効な会員だけのViewを作りましょうとの対策があります。

他にもアンチパターンとしてEAV(エンティティー・アトリビュート・バリュー)にしてしまったカラム。

通常のカラムのように、例えばtimestampカラムに”2019-02-13 19:00”と入れるのではなく、カラムにKey:Valueのように任意の属性名とそれに対する値を入れるというもの。

つまりカラム名も"key", "value"といった特定の内容に固定されなくなります。
"key"カラムに「timestamp」, "value"カラムに「2019-02-13 19:00」といったイメージになります。

たしかにこうすることでカラムに入れる内容の自由度が上がります。

ですが、カラムの型が固定されないので、県名に「東京」「東京都」が混じってしまったり、タイムスタンプも「2019-02-13」「2019/02/13」「2019.02.13」と表記揺れが出てしまって検索できなかったり、「1,2,3,4」とstringで入ってしまって1だけの検索SQLが複雑になってしまったりします。

こういうのはやめてちゃんとカラム定義しましょうね、と対策をするべきです。

こんなようにアンチパターンの具体例がわかりやすくて、そうするとこういう問題起こるよねというのが理解しやすく、さらに対策があるので理解が深まります。

自分としてはよくやってしまうんですが、バージョンアップをしないことによる大きな弊害の章は身につまされる思いで読んでしまいました。

ほんと面白かったので結局2日で読み終えてしまいました。
この本は、アプリケーションの人、バックエンドの人、またインフラやってる人も読んでみると有益かと思います。