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

11年ぶりに外部キーNightが帰ってきます。 (前回のイベントはこちら: https://connpass.com/event/11463/) この11... 外部キーに対する思いをたくさん聞けて大変に楽しい会でした。自分も言いそびれたり、盛り込めなかった内容がたくさんあるので、ここで補足しようと思います。 何が言いたかったの 外部キー制約は運用上の障壁になるだけでなく、整合性を守る仕組みとしては力不足すぎる。システム全体のことを考えたとき、不変条件はアプリケーションにエンコードせざるを得ないのだから、そちらに寄せるほうが合理的。 でした。 一定の害が存在することについては、会の中でも認められていたように思います。スキーマの変更を阻害するだとか、パーティショニングできなくなるとか、特にMySQLでは性能劣化が大きいとか、そういうやつです。懇親会でも「トレードオフとして受け入れられる」とい

[tomo_ari]

blogged

[Chisei]

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

[prograti]

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

[rck10]

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

[nippondanji]

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

[koyancya]

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

[hasiduki]

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

[taguch1]

ソフトウェアはバグるから絶対に壊れたデータは入ってくる。それを抱えたまま運用するのって長いことソフトウェアエンジニアやってもしんどい。それが少なくなるなら多少のめんどくささは許容する。

[Ep7TUEiW]

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

[ihirokyx]

外部キー制約は運用上の障壁になるだけでなく整合性を守る仕組みとしては力不足すぎる システム全体のことを考えたとき、不変条件はアプリケーションにエンコードせざるを得ないのだからそちらに寄せるほうが合理的

[fusionstar]

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

[kiririmode]

“システム全体のことを考えたらアプリに不変条件を記述することになるし、そのとき外部キー制約の出番はないよね”

[ka-ka_xyz]

アプリコード側の厳密性をそこまで信頼できる？って言われると、自分は無理。（ゴンドラ作業するときに、「安全確保はゴンドラ側の責務でありフルハーネスは二重管理で無駄」とか言わないじゃん

[aike]

仕組みとしては良いんだけど、もっと迅速に参照・操作できる標準的なGUI/CUIがあればいいなとは思う。整合性はトランザクションで保証するというのは全面的に賛成ではないけど経験的な実感としては一理ある。

[auto_chan]

「制約はアプリの責務」って考え方には共感。DBでも担保しておくのはアリだけど二重管理だし、開発中にテーブル作り直したり関心のあるテーブルにだけ雑なデータ入れようと思ったら制約にかかったり発狂しがち

[da-yoshi]

データ整合性が壊れたまま運用続けてスキーマが腐れているシステムの運用保守をやったことがあるかどうかで意見が異なる気がしている

[Error401]

そして、find_and_delete_orphan_data.shなんかを作って、cronで回す羽目になる

[PrivateIntMain]

ふつうDBはDBの世界だけで完結しているべきでアプリの都合なんか関係無いはずなのだけど、往々にして密結合になっているしアプリのデータの入れ物としてしかDBを使わないなら外部キー制約は邪魔って話かしら。

[secseek]

LinuxにRustはいらないってのと似てますね。それで問題ないなら確かにいらないんでしょう。実際、Linuxほど複雑な問題は世の中にそうはないので、大抵はあんな厳しい制約はいらないのかも

[honeybe]

キー制約が最後のガードになるからある方が良い派

[sechs]

人間が間違えないなら必要ない機能。外部キーを使うことで増加する計算コストを抑える何かがあればよい？

[MtAsuka]

外部キーはとりあえずDB定義見ただけで理解できるメタデータ定義でもあるので複雑なシステムなら必須だと思う。アプリで定義した制約は簡単に見れないでしょ？

[jojo800]

mysqlでマルチテナントの場合、異なるテナントに紐づくのはアプリで整合性担保しないといけないので気休め程度にしかならんのでは。とは思う。けどまぁ必要ない。とは思わないかな。

[devrabi]

外部キーが完全ではないからと言って、存在するメリットを大きく上回るデメリットがない限り、受け入れて利用するだけでしょう

[tettekete37564]

PHPer臭い

[versatile]

支持します。FKは人類にはまだはやい。DBはもうそろそろ自由に羽ばたけ。リレーショナルから解放されろ。もう30年以上まえからオブジェクトDBとかあるのになぁ

[monokoto01]

外部キーの役割は、アプリ側で実装するのが良いよね

[sionsou]

登壇内容を見てないのであまり強いことは言えないし、少なくとも自分より優秀な人なのでそれなりの運用や意図があってやってることはわかるけど…それでも外部キー制約は必要だと俺は思う。運用次第なのかなぁ

[onesplat]

all or nothingではないはずのものを「益がない」などと断定してしまうところがダメなのではないだろうか。益がないはずはないんだよね、トレードオフなだけで

[yosio_ism]

すべてを外部制約で解決できないからって、外部制約が要らないことにはならないんじゃないかな

[rryu]

外部キー制約を付けるとデータのストア順に制約が付くのだが、一括操作系のツールがそれに対応していないとハマるという。で、それで得られる利点は外部キーがあればその先もあるという保証だけなのが…

[mkusaka]

外部キー制約は運用負担で整合性表現が弱く、DDL（CREATE TABLE）やMySQLではStripe等の分散ケースを守れないため、アプリに不変条件をエンコードすべきと論じます。

[door-s-dev]

ON DELETE CASCADEとかは使わないってことなのか

[dodefeg]

「address = null のユーザーは商品を注文できない」は「DDLの制約」として表現可能なトリガで保証できます。なおアプリ側に集中させてDB側を単純化する、という考え方があり得ること自体は理解します。

[dekasasaki]

“より悪いことに、保証が極めて弱いことで知られる "インターネット" を通してやりとりすることになります。” ？？？

[kagehiens]

外部キー制約は面倒は確実に発生するのに、それによって守れるものがどの程度あるかというと、うーん、だからなぁ……。

[ed_v3]

まぁチームで認識あってればどっちでもいんじゃね。

[revert]

こういう人が必要としているのはRDBではないのだろうな

[ryudenx]

削除するときに外部制約があるとかなりめんどい