日常的にPostgreSQLやMySQLなどのRDBMSを使っている中で，外部キーを設定することはほとんどない．なぜなら，設定されていることで開発中のテーブルに対する操作が面倒になる(マスタテーブルのDELETEができない，など)のと，経験的にその必要性を感じることがないからだ．唯一，O/RマッピングツールであるJakarta Torqueを使ってメタファイルからスキーマを生成する際に，自動的に設定されていたことぐらいしかない(その時は後からFKを削除した)．

外部キーについては，MySQLのサイトにメリットとデメリットが記述されている．

MySQL 4.1 リファレンスマニュアル :: 1.8.4.5 外部キー
メリット

1) 関係が適切に設計されている場合、外部キー制約によって、プログラマがデータベースで不整合を引き起こすことが少なくなる。

2) 連鎖更新および削除を使用すると、クライアントコードを単純化することができる。

3) 適切に設計された外部キールールは、テーブル間の関係の記述に役立つ。

デメリット

1) キー関係を設計する上で犯しやすい間違いによって、循環ルール、連鎖削除の不適切な組み合わせなどの深刻な問題が生じることがある。

2) データベースレベルでの余分なチェックによって、パフォーマンスに影響が生じる。そのため、一部の主要な商用アプリケーションでは、アプリケーションレベルでこのロジックがコード化されている。

3) DBA にとって、個々のテーブルのバックアップやリストアが非常に困難になり、場合によっては不可能になるような複雑な関係のトポロジを作成することはめったにない。

メリット1)については，基本的にはプログラムが気を付ければ起きない．もちろん，プログラマも人間なので気を付けてもミスは起きるが，それはFKで保証するよりも，例えば正規運用前や定期的にテーブルをチェックする，参照先テーブルのキーをUNIQUEにする，といった根本的な対処が望ましいと思われる．なぜなら開発コストを考えるとFKを設定するメリットよりデメリットの方が大きいからだ(デメリット1), 3))．

一方，上に述べたTorqueなどのORマッピングツールを使う場合など，FKが設定されていることでTransaction制御の負担が減る場合があるのも確かだ．例えば，テーブルA(a_id:PK, b_id:FK)とマスタテーブルB(b_id:PK, name)を考えたとき，テーブルAのレコードを削除した際，FKが参照するテーブルBのレコードを同時に削除することが可能になる(ツールやRDBMSによる)．

しかし，こういった操作ですらTRANSACTION文を使えば保証することができるわけで，総合的な開発コストを考えるとFKを設定することの必要性を明確に述べるのは難しいことのように思われる．

■2006/02/06のチェック
・×ビジョンの意識
・×ビジョンにそった行動
・○回りの人を思いやっているか
・○はてブに3以上ブクマ
・○blogを書く
・○専門分野の知識を得る
・○専門外の知識を得る
・×仕事とは別に何かを作り続ける
・○ピアノの練習
・○朝きちんと起きる