外部キー制約は何も考えずに適用するとよくない - かとじゅんの技術日誌

このブログが話題になってますね。制約を付けること自体はよいことだけど、無目的に適用すると害も生じると思います。 無目的という言い方はおかしいな…。外部キー制約をどのように使えばいいのか、逆にどんなときに使うとまずいのかを考えてみたいと思います。 tech.tabechoku.com 例えば、これ。外部キー制約はできるだけ付けるとか、何も考えずに付けるとよくないと思います。 外部キー制約は、可能な限りつけるようにしています。 DBが別れている場合、外部キーはもちろん貼れないのですが、そうでない場合はとにかく何も考えず貼っています。データベース設計の際に気をつけていること - 食べチョク開発者ブログ テーブル設計をシミュレーションする いいたいことの結論はこれ。以上終了なのですが、もう少しわかりやすく書いてみよう。 何も考えずに外部キーを貼るのは良くないな。トランザクション境界の外で結果整合性

[turanukimaru]

物理削除反対派です。商品は削除しません。終売になります。消して良いのは「現在しか存在しない」データだけと考えています。例えば商品の一部のコピーとして現行取扱商品は削除しますが商品そのものは残したいです

[buhoho]

"商品単体での削除ができません" うーん。そのための制約なので狙い通りの動きっぽい。商品が存在しない売り上げって考えられないので、自分なら商品単体の削除は許さない。例が悪いだけなのかな…

[Kil]

？？？　商品が消されたあとの売上詳細をみたら、なんの商品の売り上げかわからなくなるじゃん。それはまずいから外部キーで守る。売上と商品の関係だと、むしろ外部キーをつけておかないと困る例では？

[napsucks]

商品の売価変えたら売上レポートの金額が変わったという間抜けな話を思い出した

[uunfo]

売れた時の商品情報は価格と名前以外も全部コピーしておくべき

[crexist]

ちょっと例がよくない気がします。売り上げに会員IDを紐付けて購入履歴が見れる様にするという例であれば、その際会員IDが FK だと退会時に会員を物理削除することができなくなるという話にできて納得感があるかと

[khtno73]

売上というか関連明細発生した商品削除できない(しちゃいけない)のは販売購買在庫の業務システムでは割と一般的なので、こんな例出せばそらブコメは紛糾する。終売/終息フラグか年月日入れて新規取引発生不可よね。

[ys0000]

斜め読みしたけど、売り上げの明細に入った時点で元の商品と分けなければならない。廃盤、価格改定、増税、キャンペーン値引き等々。商品がスキーマで売り上げがインスタンスって感じかなぁ。

[night_face]

ネットショップで働いているけど、商品を削除ってどういう時？！大体データは残して販売休止にすると思う。同一商品を出品し直す場合、過去の売上連動できないから別IDで出品するし、そのユースケースが想定できない

[nminm]

「商品も勝手に消されると困るから制約があっても良いのでは？」みたいなコメントを書かれている方は、実際に商品を消す処理を想定してみるといいかもですね。（より重要な）売上詳細もいじる必要が出てくる怖さ。

[moneyshark]

イベント系とリソース系に分けて考える 系統が違うものは、FKいらない(削除を考えてつける)

[tmatsuu]

追記の部分も外部キー制約はON DELETE SET NULLなりSET DEFAULTを使えば適用できるよ。その状況で適用できないのは外部キー制約ではなくNOT NULL制約な気がした。

[rryu]

要は依存関係のないエンティティ間のリレーションの時ということだと思うが、DB的にはNULL可な外部キーカラムというだけで外部キー制約が付けられない訳ではない。

[kiririmode]

“結果整合性を求める用途では外部キー制約は使えない。トランザクション整合性のある境界内では使える”

[sds-page]

基本論理削除でデータの入れ替えする時の邪魔にしかならんから外部キー制約は使わないかな

[everybodyelse]

物理削除も論理削除もやめて、全てのデータは必ず残してステータスだけで管理するのが良いような気がしている。削除ではなくアーカイブとして履歴テーブルに複製していく感じ。個人情報は適当なデータで上書けばいい

[juve534]

「外部キー制約はとりあえずつけた方が良い」というイメージでしたが、トランザクション境界を考えると、一概にそう言えないんですね

[takeshiketa]

外部キー必須とは言えないみたいなのに理由付けするの、Rails普及期によくあった。それと同じとは言わないけどさ。

[yojik]

DDDの集約の考え方を守るためだけに、RDBMSのデータ整合性を守るFKをオミットするする問題（そもそも両者相容れない存在なのかも）。あと商品に関してはそれとは別問題で売上明細用のスナップショットが必要だと思う

[mitchell1983]

ON DELETE SET NULL

[moro]

昨日から何度か読み返してみたけど、やっぱり外部キー制約あったほうがいいじゃんね、という気持ちになる。もとの食べチョクさんの意見に賛成で、現在は迷ったらつけるでいいんじゃないですかね

[letitride]

この手の話し、FKもnullableも削除フラグも必要があれば使用するし、必要なければ使用しないと考えておけば気が楽。記事の例でいうと商品の変更履歴を残しておくという要件があれば、 また違ってくるし、設計大事

[deztecjp]

出した例に問題があると、本題そっちのけで例へのツッコミばかりになるパターン。／「初心者はとりあえずこうしておこう、後で苦労するけど致命的ではない」的な知恵がほしいけど、「そんなものはない」で終了か。

[kae1990]

まぁ外部キー制約は多くの場合不要だろう。整合性が取れなくなるのは運用が間違ってるケースだ

[nakag0711]

商品価格をマスタからコピーしないで商品コードだけ記録するのは初心者のよくやるミス

[lifeisadog]

削除したい時って間違えて登録しちゃった時とかだよね

[Error401]

この記事の内容を受け入れる前に、「結果整合性」とは何かを調べ、SQLアンチパターンの「4 章 キーレスエントリ（外部キー嫌い）」を読むことをお薦めします。私はこの記事は害悪だとすら思う。

[aike]

FK制約の話というより履歴テーブルは正規化しすぎないという設計頻出パターンの話か。追記にあるけど悩ましいのは退会して個人情報削除請求があったとき。

[twotiger]

外部キー制約は滅多に使わないな。仕様変更耐性やデータの一括操作時に足かせになる。商品レコードを削除する（論理でも）ケースはまずなくて、ステータスカラムでユーザーに非表示にするのが普通のECサイトだと思う

[yamadadadada2]

例の良し悪しは置いといて、変更容易性を保った設計実装は意識したい。制限があればいいってもんじゃないという主張は同意

[shikiarai]

終売、絶版、削除フラグを用意しないとゲロ吐きそうになるよね。画面上永遠に入荷待ちとしか表示できなくなったりする

[mohno]

追記されてるが例が悪いというか、「忘れられる権利」も個人情報消せばよいのでは。アカウント名の再利用を考えるなら、それで制約かけちゃいかんというのはありそうだけど、それはそれで運用が難しくなる気はする。

[chinpokomon_master]

言いたいことはわかるが本人も書いてる通り本当に例が悪かった。そして何かを否定する時は慎重にならないといけない。誤解されてから「本当はこういうつもりだった」と追記したところで誰も見てはいないだろう。

[dagama]

データ設計なんてのはどうせすぐに変わっていくものだから制約は無いに越したことはない　アプリ側単体テスト(DBへのI/O部分含む)の邪魔になったりもするし

[sinsoku]

外部キーあるレコードも削除できるし、説明があっていない気がする。

[circuit_breaker]

https://note.com/masuidrive/n/n2d631eee2bef これを思い出した。泥臭い運用を確実に避けることが前提かもしれないけど、自分には自信ないなー…

[uva]

こういう判断の連続・積み重ねなのでソフトウェア開発の難しさがわかる

[oktnzm]

この場合でも制約つけない設計もあるだろうが設計思想の話になる。そういう意味では不適切な例。個人的にはパフォーマンスの問題で現行商品と過去分を分けるというのはやる。でも完全削除はやらない。

[Makeneko]

なんとなく、例が悪そう。