SQLアンチパターンを読んだ
3ヶ月くらい積読されてたのを引っ張り出して読んだ。例によって、読み始めるとめちゃめちゃ面白くて何故こんな素晴らしいものを積読してたんだ...って感じだった。
ざっくりとした感想
けっこう色んな人が読んだ感想とか内容を簡単にまとめたものとかを書いてるので、ぶっちゃけ今更な気もするけど簡単にまとめとく。
この本ではSQL(というかRDB)のスキーマ設計とかクエリの投げ方とかで陥りがちなアンチパターンを25個に絞って順に解説していってる(1章で1つのテーマを扱うので、ちょうど25章ある)。25章とか多すぎるんじゃってビビってたけど、むしろ1章1章のボリュームは抑え気味で簡潔にまとまってて読みやすかった。
アンチパターンって言っても頭ごなしに否定する訳じゃなくて、どういう意図があってそのアンチパターンを採用してしまうのかとか、より良い解決策は何なのかとか、そういった事が順に説明されてく構成だった。「何を避けるべきか」だけで無く、「どう進むべきか」の指針も打ち出してくれてて、嬉しかった。
自分にとってはⅠ部の「データベース論理設計のアンチパターン」で扱われてた5~8章が印象的で、特に「データのメタデータへの混入」や「メターデータのデータへの混入」を避けよう、みたいな特定のパターンに依存しない心がけを知れたのが良かった。8章の「メタデータトリブル」で扱われてたケース(データであるはずの「年代」をメタデータであるテーブル名として採用してしまう)はけっこうやってしまいそうな気がしたので、まずいって感覚を掴めたのは良かったと思う。
24章. マジックビーンズについて
24章はモデルをアクティブレコードそのものとして扱うことへの弊害について書かれていた。この辺のこと(特にRailsにおいてActiveRecord::Baseを継承したオブジェクトがmodelとして扱われること)はこれまでに多くの人がいろんな議論をしていて、自分の中でもいろいろ思うところがあったので、ちょっとまとめておく。
まずは用語の定義から。マーティン・ファウラーがPoEAAで取り上げた「アクティブレコードパターン」はモデルオブジェクトのクラスをテーブルと対応付け、1つのオブジェクトをテーブルの1行と、オブジェクトの1つのフィールドをテーブルの1つの列と対応付けるというもの。アクティブレコードは基本的なCRUD操作をサポートする。実は今挙げた点だけだと「Row Data Gatewayパターン」(これもPoEAAで取り上げられてるもの)と全然違いはなくて、ただアクティブレコードは domain logicを含む という点でRow Data Gatewayとは違う。
よく問題だと言われるのが、アクティブレコードをデータアクセスオブジェクト(DAO)としてしか使わず、Controllerにロジックを書いてしまうというもの。正直、これに関してはModelやControllerの役割を理解してれば絶対にしない事だからあまり問題じゃ無いと思う。
また、別の点でよく突っ込まれるのは
- アクティブレコードはモデルをデータベーススキーマに強く依存させてしまう
- アクティブレコードを用いると1つのクラスで扱う仕事が多くなり過ぎる
みたいな点で、これはまあその通りかなと思う。というか、アクティブレコードだけを用いてモデル層を記述しようとすれば、そりゃこういった問題は出て来るだろうという感じ。
PoEAAの中でマーティン・ファウラーも言ってるんだけど、そもそもアクティブレコードはロジックの薄いモデルを扱うときに便利なパターンで、複雑なロジックを記述するには向いていない。だからまあ複雑になってきたらDAOとしての機能は切り出して別のモデルクラスにロジックは書くとか、そういった感じで対処すれば良いしそれが望まれてるんだと思う。
この辺は既に経験豊かな優秀な人たちがたくさん議論してて、Web上にもいっぱい情報が落ちてるのでそういった情報を参考にしながら適宜対処していけば良さそう。
