それでも外部キー制約は必要ない / #fk_night でしゃべってきました

blogged

外部キー制約、正規化を使って設計する人にとっての強い味方って感じなので、そうでない人にとっては無用の長物というのは、それはそうって気がする

FK不要論は定期的に燃えるけど、実務で整合性ぶっ壊れた時の絶望を知ると外せなくなる

"ACIDで言えば、A（原子性）D（持続性）には強く期待していますが、C（一貫性）は別の機構で守るべき" / 業務上の「整合性」とRDBの「整合性」にはギャップがあって不便だよね、という意味では同意。

システムを保守していると外部キー制約違反のバグとかよく遭遇するし、業務システムだとテーブル数が数百とかあって色んな人がスポットで保守に関わるから、個人的には制約付けた方が良いんじゃないかと思います

個人的には理解できる。薦めるかというとうーん

“外部キー制約は運用上の障壁（スキーマの変更を阻害する、パーティショニングできなくなる）になるだけでなく、整合性を守る仕組みとしては力不足すぎる。不変条件はアプリ側に寄せるほうが合理的。”

リレーショナルモデルが力不足って、リレーショナルモデルを理解してないだけではなかろうか。

ルールベースの運用は守らない者が現れた時にダメージがでかいので制約ベースが安全です。

“単に運用がつらいから制約を弱めようという話をしているのではなくて、システム全体のことを考えたらアプリに不変条件を記述することになるし、そのとき外部キー制約の出番はないよね、という風にご理解いただけ”

webのバックエンドにある時の相性の話？

多層防御というか多層障害発生対策は全然ありで、コスパも良い方かなと思う。コストには速度低減も含めたうえで

データベース設計でシステム全体の整合性は保てないはわかるけど、アプリの条件がどうあれ外部結合の整合性は守られないと怖いよね。 アプリケーション層とデータ層の話を混ぜ返しているように見える。

設計上では必要でも実務では邪魔。そんな外部キー。

そのテーブル群を使って開発してるのが一つのチーム、一つのアプリ群ならそうかもしれないっすね

クリーンアーキテクチャとかではそうだよね。DBを気にしてモデリングなんてしないからな。

DB制約がドメイン制約として不十分なのは同意！！！！！！でも！！！！両方あってもいいよね！！！！！！

アプリ通さないこともあるしバグもあり得るからな。のり代程度でも入れといた方が良い

テストデータ作りにくいんよな

外部キー制約サポートがなかった時代からの古株のRailsユーザーが言いそう。