RailsのActiveStorageってアンチパターンなの?
通称 "達人本" として知られている「達人に学ぶDB設計徹底指南書: 初級者で終わりたくないあなたへ」を読んでいると、"DB設計において「ポリモーフィズム」はアンチパターン" という旨の記述がありました。
「ほぇ〜、そうなんだ〜」くらいに間抜けな顔していましたが、よくよく考えると、
「ん!? そういえばRailsのActiveStorageってポリモーフィズムを使っているような気がするんですけど!!!」ってなったので、調べてみました。
余談
噂通り、めちゃくちゃ神本でした。
5章以降が特に実務によった内容で、とても勉強になりました。
「正規化は知っているけど、実際の仕事ではどういう思想をもって設計したら良いんだ?」ってなっている方は4章までは飛ばしても良いかも。
結論
Rails様、いつもお世話になっているのに疑ってすみませんでしたmm 🙇♂️
大事なので一応、2回言っておきますね。
大事なので一応、アラートも出しておきますね。
ということで、その結論に至った経緯をまとめていこうと思います。
達人本では、なぜアンチパターンとされていたのか?
達人本では、単一参照テーブル(ポリモーフィズム)を使ったDB設計がアンチパターンとされていました。
しかし、「一概にポリモーフィズム = アンチパターン」というわけではありません。
内容の本質は、DB設計においても 「単一責任の原則」 に沿って設計することが重要ということでした。
達人本で例として挙げられていたケースは、テーブル構造が同じなので、単一テーブルでデータを保存していました。
この例でのポリモーフィズムの採用理由は、「テーブル構造が同じ」という理由のみで、構造は同じですが それぞれのテーブルには異なる責務を持ちます。
誤った理由でポリモーフィズムを採用すると、以下のデメリットが生じます。
- SQLでどのテーブルかの指定を間違えても返る値が変更されるだけでエラーにならないため、バグが起きても気づきにくい
- ER図はスッキリするが、モデルとして正確性を欠いているので、可読性は下がる
- ユースケースによってはレコード数がかえって多くなり、パフォーマンスが低下する
百害あって一理なしな設計です。
ActiveStorage でのポリモーフィズムの使われ方
一方、ActiveStorageでは「モデルにファイルをアタッチする」という、どのモデルに対しても一貫した責務を持ちます。
これは、単一責任の原則には反していません。
むしろ、どのモデルでも共通して使用される可能性がある横断的な関心事といえます。
さすがRails様!!!!!
まとめ
- ActiveStorageはアンチパターンではない
- ポリモーフィズムを使う際も、単一責任の原則を守ることが重要
Discussion