外部キーNightに行ってきた #fk_night

外部キーNightという勉強会に参加してきた。Validation Night、テンプレートエンジンNight、ページャNightでおなじみのなんとかNightシリーズで、今回はDBの外部キーがテーマだった。

実況

外部キー制約はパーティションを使えない・リレーションの親テーブルをロックしてしまうので規模によってはよくない。けどデータの組み合わせで安心を得られるので、規模の問題が解決しているのなら使いたい #fk_night

— かとりょー the 新卒 (@katryo) February 13, 2015

「MySQL国の人はCHECK制約を知らない」 #fk_night

— かとりょー the 新卒 (@katryo) February 13, 2015

MySQLは即時制約チェックしか対応していないが、他のRDBMSは遅延制約チェックにすることができる。たとえばトランザクションコミット時に制約チェックが入る。MySQLの不便さよ…… #fk_night

— かとりょー the 新卒 (@katryo) February 13, 2015

まずいとわかってはいるけれど、着任したら ON DELETE CASCADEのときもある #fk_night

— かとりょー the 新卒 (@katryo) February 13, 2015

カタストロフィに仕様変更で立ち向かう勇者の話だ #fk_night

— かとりょー the 新卒 (@katryo) February 13, 2015

主キーとは別にUNIQUE制約をかけることで、ORマッパーを使いにくい問題とJOIN地獄問題を解決した話だった #fk_night

— かとりょー the 新卒 (@katryo) February 13, 2015

まとめ

自分なりのまとめです。

外部キーは大いに使うべきだ。外部キーは、暗黙のルールを制約として明文化し、かつDBの中身もそのルールに沿わせるもの。ルールの遵守により誤解、ミスを減らせる。

ただし、注意点もある。デッドロックやON DELETE CASCADEといった挙動により、予想外の損害が発生しうる。制約から得られる利益は十分に大きいため、外部キー制約に対する各RDBMSの仕様を理解することで、これらの問題に対応すべき。

理想的にはDBに触れる人すべてが外部キーの仕様に馴染んでいてほしいが、そうでないときも詳しい人が一人いると全然違う。ミドルウェアに精通したRDBMSおじさんを理解するととても頼れる力となる。RDBMSを使うときは（もしおじさんがいるなら）外部キー制約についてよく話しあってルールを決めてから設計すると、一貫性がありメンテナンスしやすいDBになる。