失敗から学ぶRDBの正しい歩き方

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

全体的にハラハラしながら読み進めることができてよかった。こんなことがあるのか、みたいな気持ちになりながら読む人もいるかもしれないけど、こんなことというのは起こりうるものである。

WebアプリケーションにおけるJOINだと、O/Rマッパを使ってないとき*1昔はよくやってたけど、今だと SELECT * FROM a したあと SELECT * FROM b WHERE a_id IN (...) してからアプリケーションでくっつける書き方のほうがすぐできるようになった。アプリケーションはスケールさせやすい、クエリを分けて書くと個別にチューニングしやすい、みたいな話題だと思う。

腐ったテーブル設計にしないのが一番よいけれど、知識が蒸留されていなかったとか、とにかく開発速度を上げるためにデータモデリングを犠牲にしたとか、いろいろな事情があって腐ってしまうこともあると思う。借金のようなものが強くのしかかってくる状態なので、どこかで工数をかけて返済したい。

*1:ISUCONとか