Webでもアプリでもデータが肝だから、テーブル設計力を鍛えたい 楽々ERDレッスン
idは振ってあって欲しいと思うのですが
設計を勉強し始めた頃に手に取った本には、「id（railsがオートインクリメントで振ってくサロゲートキーを指す）みたいな項目はいらん」と書いてありました。フレームワークがデフォルトで振ってくれる項目を不要、と考える人がいるなんで想像もしなかったので、衝撃的でした。
それから半年、会社の人に勧められて手にとったこの本は「idは振っておくべきだよね」と書いていました。ですよね。。。
楽々ERDレッスン
(株)スターロジック 羽生 章洋
翔泳社
売り上げランキング: 30,447
idはやっぱり必要だよね
データの洗い替えに耐えられない。これは十分すぎる理由ですね。id使わないとデータの洗い替えで関連テーブルを巻き込むことになります。
洗い替えが起こるようなデータを外部キーに使って設計すんな、と言われそうですが、予期せぬ箇所で洗い替えが起こっても問題ない設計にしておく方が正解なんだと思います。実際、何年も開発続けてると、仕様の根幹が変わること、まあまあありますよね。先々のことなんか読みきれないから、多少無駄でも柔軟な設計にしておくの、大事かなと思います。
動詞と名詞を分けるという考え方
業務フローをステータス遷移で表現しているコードを多く見ていたせいで、イベントとリソースを分ける、という考え方がこれまで全くできていませんでした。
あるデータが作られ、ある人の元に渡り、ある人に差し戻され、またある人の元に行き、役目を終える、みたいなのをstateカラムで表現してるコードです。
ステータスが変わった時のtimestampを取っておきたい場合に、別途ログ用のテーブル を用意したり、「AからBに遷移した時のtimestamp」カラムを持たせたり、色んな設計のコードを目撃しましたが、データとイベントを分けておけば、イベントレコード生成時のcreated_atが遷移した時のtimestampになりますね。
実績系、計画系、分析系
実績系、計画系、分析系、というシステムの系統、という考え方があることを知りました。系統に合わせてデータ設計を変えるべきなのですね。これはまた別の書籍を読んでみたい。
現実のものをベースに考える
楽々ERDレッスンは、上記の話が書いてある第一部の後、第二部ではRDBMSそのものにまつわる話、第三部ではレッスン編、と続いています。
レッスン編では、日常に転がってるレシートや請求書などから、DB設計を考えるのですが、現実のものをベースに考えるのって、当たり前ですが大切ですよね。
定義書や画面イメージ、コードばかり見ていると、実際の帳票がどうなっている、とか、業務フローがどうなっている、とか、うっかり忘れてしまいますが、忘れたらダメです。
自分が見聞きした設計のコツ
楽々ERDレッスンのアウトプットと合わせて、これまで自分が見聞きした設計のコツを列挙してみようと思います。
パフォーマンスを意識した非正規化を考えない
パフォーマンス良くなりそう、という理由で、最初から非正規化したデータをもたせた設計にしてみることがありますが、経験長い人曰く、それはパフォーマンス悪い時に考えれば良いことで、いきなり考えることではない、とのことです。
下手の考えなんとやら、なのかもですね。作ってみて遅かった時初めて考えるべきなのかも。
現実にない概念を設計に持ち込まない
帳票やフローにはないシステム内だけの概念を設計の都合上つくったが、後になって他の箇所と辻褄合わなくなってきて辛くなる、というのを経験したことがあります。現実にない概念、って、現実と辻褄合うように作るのが難しいのだと思います。あと、現実はシステム内概念とは関係なく、現実にあるルールに則ってどんどん進んでいくので、置いて行かれるんでしょうね。