エンジニアが終末に備えて技術を磨く日記の32日目。
1日目はこちら。
「エンジニアが終末に備えて技術を磨く日記」カテゴリはこちら。
『達人に学ぶDB設計 徹底指南書』を読みました。DBの設計方法、冗長化、バックアップ、ER図の書き方、パフォーマンスを向上させるためのテクニックなど、DBを扱うために必要な知識が広く浅く解説されている本です。
難しい事は書かれておらず、用語にも都度説明が挟まるので、DBに関してほぼ知識のない僕でも読めました。DB触りたての初学者向けの本という感じです。
自分用のWebアプリの処理速度がレコード数の増加とともに遅くなってきているので、その改善に役立つのではないかと思って手に取りました。
ただ、この本が役に立つのは「業務で顧客のデータを扱う場合」「1万レコード以上のテーブルを扱っている場合」だと感じました。
責任あるデータを扱っている場合は、冗長化やバックアップの情報が役に立ちますし、1万レコード以上のテーブルを扱っている場合は、パフォーマンス向上のためのテクニックが役に立ちます。
逆に、1万レコードもないテーブルのパフォーマンスを向上させたい場合、この本を読む必要は無いと思いました。それくらいの規模なら、正規化すれば問題は解決する。この本に頼るべきは「正規化したのにパフォーマンスが足りず、さらなるパフォーマンスの向上が必要となっている人」だと思います。
僕のWebアプリは1万レコードもなく、処理が遅い原因は十分な正規化ができていないからなので、つべこべ言わずまずは正規化するべきでした。
いや、まあ分かってはいたんですよ。全然正規化されていないクソみたいなテーブル設計をしてしまったせいで、1つの情報を取り出すのにテーブルを何度も舐めまくっているのが遅い原因だって。だけど、テーブルを再構築するのが面倒だったから、何かテクニックでサクッと解決できないかなと思って読んだんです。そんなテクニックはありませんでした。
ただ、大規模なデータや責任のあるデータを扱う時、問題が生じたら何を調べるべきかが分かったので、良しとします。
エンジニアとしてサービスを運営していると、早急な対処が必要な問題が急に現れることがあります。色んな分野の知識を広く浅く知っていると、そういう問題が起きたときにすぐに調査に着手できるという安心感があります。
まあ、会社に属してサービスを運営している場合、どんなニッチな分野でも強いエンジニアは社内に1人くらいいるので、雇われエンジニアに「万が一のための広く浅い知識」が必要かと言われるとそうでもないのですが……。