TLで良書だというのをチラホラと見かけていたのだけれど、結構古い本なので迷っていたのだが、今でも通用しそうな内容っぽいので買って読んでみた。
TLで見かけてた、楽々ERDレッスンを手にいれたので読んでいく。 pic.twitter.com/f7WEl6mHft
— パトラッシュ@エキスパート職 (@patorash) 2021年2月1日
感想から書くと、これもまた「UNIXという考え方」と同じで、もっと若いうちに読みたい本だった…😇
この本の内容を知っていれば、データベース設計で悩むことも相当減っていたと思うし、プログラムで苦しむことも減っていたと思う。つまり、この本は「買い」です。かなりお薦めできる。もう読んでいる途中から社内のTeamsでは良書だと言いまくった。めちゃめちゃプッシュしたからか、後輩の何人かも買ってくれたみたいだった😋
ちなみに「UNIXという考え方」の感想はこちら。
DB設計総論
データベース設計をする際に見ていく手順がまとまっているのがよかった。特に、イベント系から洗い出して、イベント系の正規化をしてから、リソース系を洗い出す、というのは目から鱗だった。
Railsに慣れているから、リソース系から洗い出そうとしてしまう癖があったので、ここはめっちゃ唸った。イベントという、事実を記録するところが大事。One fact in one place.（1つの事実を1つの場所に）。正直、これが今のプロダクトで出来ていない。1つのテーブルに2つのイベント系が含まれてしまっている。そのせいか、クエリも複雑になるし、カラム数は増えるしで、プログラムのハンドリングも難しくなっていたのだが、かといってこれを読むまでは特に疑問も抱いてなかった。あー、リファクタリングしたいー！！
また、よくRailsのActiveRecordで批判される、テーブル毎にIDを振るという仕組みについても、このままでいいんじゃないかという自信になった。サロゲートキーを使うほうが、変更に強いシステムになり得る。コードを個別に作ることはいいことだが、そのコード体系に矛盾が生じた場合、外部キーに使っていたら大変なことになるというのは、確かにそうかも…と思った。サロゲートキーであれば、そういう問題は起きないので、コード体系は個別に仕様変更可能。
あとは状態の遷移をフラグで管理するか、個別のエンティティを作るかというところも面白かった。似ているけれども違うもの。フラグで管理しているとさも共通化出来ていそうにみえるけれど、状態が違うということはビジネスロジックが違うということになる。単純な状態だけならば、フラグでもいいかもしれないけれど。
この章で心強かった言葉を抜粋する。正規化について。
「いかに正しくするか」ではなく、「いかに無理なくムラなく無駄なくするか」というふうに考えればそれでよいと思い至ったときです。
RDBMS総論
データベースを使うことのメリットや、なぜデータベースが生まれたのか？という背景に話が移っていて興味深かった。RDBMSは極論いうと、レポート生成機である。レポートをいかに簡単に作り出せるか、そのために生まれてきたもの。昔はエンジニアが考えたフォーマットで蓄積されていたデータしかなかったので、いいレポートを作るアイデアを思いついても、エンジニアにお願いするしかなかったが、RDBMSができたことで、SQLさえわかればすぐに試すことができるようになった。RDBMSはエンジニアという特権階級からのデータの解放。と書いてあったが、十分難しいぞ、SQL…。しかし、SQLが分かればすぐレポート作れるのは確かにそうである。
データは活用されてナンボで、使われなければただのゴミ…。それはこの前のOSO2020の話に通じるものがある。
データ中心アプローチ(DOA)
DOAの本質についての話は面白かった。データという客観的なものを通じて、業務プロセスのムダ・ムラに切り込んで企業を変えていくという壮大な話だった。単なるデータ設計の話ではない。
DLC（データライフサイクル）から考えて、データの正規化から、さらに踏み込んでトランザクションの正規化、そこからUIの無駄を省き、ユーザの役割の正規化、組織の正規化へ…。設計はワークフローを変えて、組織を変える力もある。
数学的正規化と業務的正規化
教科書的な正規化では、実際の業務に沿った正規化にならないケースが殆ど。想像力を働かせてヒアリングをして業務的正規化に落とし込んでいく。ERDとは、ビジネスの写像という表現にグッと来た。
論理設計と物理設計
非正規化についての話があった。本当に非正規化は必要なのだろうか？非正規化は時代遅れ。ハードウェア性能は目覚ましく良くなっている（この本は2006年の本だけれど）。なぜ非正規化が大事と言われていたかを考えてみると、1980年代はハードウェアが遅いし高価で容量も少なかったため、少しでも容量を節約したり高速化するために必要な手段であった。しかし、その手法を未だに引きずっているのはナンセンスではないか？というのが筆者の意見だった。これもまためっちゃ唸った。正規化した後、「でもまぁどこか非正規化したりせんといかんのかな…？」とか気にしていた自分がいたが、もう基本的に気にしないことにする。非正規化は、せっかくやった論理設計を無駄にする作業になる。
現代においては、インデックス設計が物理設計といっても過言ではない、とあった。なぜインデックスを使うのか？の説明があったが、まぁそのあたりは知っているのでサラッと流した。ただ、検索が優先か、更新が優先かという話もあるが、更新においても検索が重要な意味を持つので、インデックスが必ずしも更新性能を落とすわけではない、というふうに書いてあったのは気付きがあってよかった。
SQLはバッチ処理
SQLはバッチ処理であるということを知らずにプログラミングすると、N+1問題が発生するようなコードを書きがち、という話が書いてあった。めっちゃわかる…。特にActiveRecordに頼っていてSQLを全然意識しない人はそういうのやりがち…。
SQLに詳しくない人のために、ストアドプロシージャでSQLを隠蔽した関数を作って、それを使わせることで効率の良い開発を行うという手法が紹介されていた。ActiveRecordで簡単にデータが取れる現代においては微妙な開発手法であるけれど、これは経験的にめっちゃわかる。
もう15年前くらいになるけれど、当時、自分含めて数人がSQLが全然わからなかったのだが、複雑なJOINをしなければならず、全く歯が立たなかった。そのため、データを取得する箇所はSQLを書ける人が担当して取得用メソッドを作るように分業をしていたことがあった。そのおかげでこちらはメソッドを呼び出すだけで必要なデータが取れた。ストアドではなかったけれど、同じようなことだ。これの何がいいかっていうと、SQLをよくわかってない人から、データを守ることができる。間違ってデータを壊すようなSQLを書かれなくて済む。DBAだけがストアドでカプセル化したSQLを関数として提供することで、安全かつ効率のよい処理ができるし、テストはそのストアドのテストを行えばいい。金融系や個人情報に厳しいシステムならば、この手法は良さそう。
ERDレッスン
レシートや予約受付、注文用紙を元にERDを書いていくというレッスンがあって、すごく頭の体操になってよかった。解説もわかりやすかったし、こういうケースも想定できるよというヒントもあった。ここは買って実際にやってみるのをお薦めしたい。
付録
付録では、EXPLAINの読み方がダイアグラム付きで書いてあってよかった。EXPLAINは最初はなんとなくとっつきにくくて思考停止してしまいがちなのだが、こういう図で示されるとわかりやすいのではないかと思う。そういう意味でも若い頃に読みたかったというのはある。
あとはボトルネックの原因と対策についてが書いてあったが、普通に気を付けることが書いてあったが、経験が浅いと知らないことかもしれないので、ここも若いうちに知っておくべきことだなぁと思う。
つまり、付録もすごく有用！！
全体を通して
この本自体は初心者向けというよりは中級者向けではある。正規化についての説明とかはほぼなくて、それは知っている前提なので、基本情報技術者試験に受かってるレベルの人が読むとすごくいいと思う。
なぜデータベースが生まれたのか？というところから遡って、故にデータベースはこういうものである、という話で進んだので、とても内容が腹落ちしやすかったし、時代に即した設計しようぜってのもウンウン頷きながら読めたし、非常に楽しめたし今後の仕事に活かせそう。
Webアプリケーションエンジニア全員にお薦めできるのではないだろうか？（主語が結構でかい…😅）
- 作者:(株)スターロジック 羽生 章洋
- 発売日: 2006/04/18
- メディア: 単行本（ソフトカバー）
