blogged
外部キー制約、正規化を使って設計する人にとっての強い味方って感じなので、そうでない人にとっては無用の長物というのは、それはそうって気がする
FK不要論は定期的に燃えるけど、実務で整合性ぶっ壊れた時の絶望を知ると外せなくなる
"ACIDで言えば、A（原子性）D（持続性）には強く期待していますが、C（一貫性）は別の機構で守るべき" / 業務上の「整合性」とRDBの「整合性」にはギャップがあって不便だよね、という意味では同意。
システムを保守していると外部キー制約違反のバグとかよく遭遇するし、業務システムだとテーブル数が数百とかあって色んな人がスポットで保守に関わるから、個人的には制約付けた方が良いんじゃないかと思います
個人的には理解できる。薦めるかというとうーん
“外部キー制約は運用上の障壁（スキーマの変更を阻害する、パーティショニングできなくなる）になるだけでなく、整合性を守る仕組みとしては力不足すぎる。不変条件はアプリ側に寄せるほうが合理的。”
リレーショナルモデルが力不足って、リレーショナルモデルを理解してないだけではなかろうか。
型やテストと違って本番環境にも確実に影響が出る、と考えると理解/説明し易いかも。
ルールベースの運用は守らない者が現れた時にダメージがでかいので制約ベースが安全です。
“単に運用がつらいから制約を弱めようという話をしているのではなくて、システム全体のことを考えたらアプリに不変条件を記述することになるし、そのとき外部キー制約の出番はないよね、という風にご理解いただけ”
webのバックエンドにある時の相性の話？
多層防御というか多層障害発生対策は全然ありで、コスパも良い方かなと思う。コストには速度低減も含めたうえで
データベース設計でシステム全体の整合性は保てないはわかるけど、アプリの条件がどうあれ外部結合の整合性は守られないと怖いよね。 アプリケーション層とデータ層の話を混ぜ返しているように見える。
設計上では必要でも実務では邪魔に感じてしまう。そんな外部キー制約。
そのテーブル群を使って開発してるのが一つのチーム、一つのアプリ群ならそうかもしれないっすね
クリーンアーキテクチャとかではそうだよね。DBを気にしてモデリングなんてしないからな。
DB制約がドメイン制約として不十分なのは同意！！！！！！でも！！！！両方あってもいいよね！！！！！！
アプリ通さないこともあるしバグもあり得るからな。のり代程度でも入れといた方が良い
テストデータ作りにくいんよな
外部キー制約サポートがなかった時代からの古株のRailsユーザーが言いそう。
sqlはStructured Query Languageの略で、queryは質問、疑問、問い合わせといった意味。つまりReadに特化した言語。Writeに特化したspl(Structured Post Language)を作ろう。
削除するときに外部制約があるとかなりめんどい
こういう人が必要としているのはRDBではないのだろうな
まぁチームで認識あってればどっちでもいんじゃね。
外部キー制約は面倒は確実に発生するのに、それによって守れるものがどの程度あるかというと、うーん、だからなぁ……。
この手の意見の不一致ってシステムの種類、規模、状況次第で、そこを揃えない議論は無意味 。業務システムならバッチでどうとでもなるし、C向けシステムみたいに大量のリードや更新を同期処理するなら無理だろう。
ソフトウェアはバグるから絶対に壊れたデータは入ってくる。それを抱えたまま運用するのって長いことソフトウェアエンジニアやってもしんどい。それが少なくなるなら多少のめんどくささは許容する。
“より悪いことに、保証が極めて弱いことで知られる "インターネット" を通してやりとりすることになります。” ？？？
「address = null のユーザーは商品を注文できない」は「DDLの制約」として表現可能なトリガで保証できます。なおアプリ側に集中させてDB側を単純化する、という考え方があり得ること自体は理解します。
ON DELETE CASCADEとかは使わないってことなのか
外部キー制約は運用負担で整合性表現が弱く、DDL（CREATE TABLE）やMySQLではStripe等の分散ケースを守れないため、アプリに不変条件をエンコードすべきと論じます。
外部キー制約を付けるとデータのストア順に制約が付くのだが、一括操作系のツールがそれに対応していないとハマるという。で、それで得られる利点は外部キーがあればその先もあるという保証だけなのが…
すべてを外部制約で解決できないからって、外部制約が要らないことにはならないんじゃないかな
all or nothingではないはずのものを「益がない」などと断定してしまうところがダメなのではないだろうか。益がないはずはないんだよね、トレードオフなだけで
登壇内容を見てないのであまり強いことは言えないし、少なくとも自分より優秀な人なのでそれなりの運用や意図があってやってることはわかるけど…それでも外部キー制約は必要だと俺は思う。運用次第なのかなぁ
外部キーの役割は、アプリ側で実装するのが良いよね
支持します。FKは人類にはまだはやい。DBはもうそろそろ自由に羽ばたけ。リレーショナルから解放されろ。もう30年以上まえからオブジェクトDBとかあるのになぁ
PHPer臭い
外部キーが完全ではないからと言って、存在するメリットを大きく上回るデメリットがない限り、受け入れて利用するだけでしょう
mysqlでマルチテナントの場合、異なるテナントに紐づくのはアプリで整合性担保しないといけないので気休め程度にしかならんのでは。とは思う。けどまぁ必要ない。とは思わないかな。
外部キーはとりあえずDB定義見ただけで理解できるメタデータ定義でもあるので複雑なシステムなら必須だと思う。アプリで定義した制約は簡単に見れないでしょ？
人間が間違えないなら必要ない機能。外部キーを使うことで増加する計算コストを抑える何かがあればよい？
キー制約が最後のガードになるからある方が良い派
LinuxにRustはいらないってのと似てますね。それで問題ないなら確かにいらないんでしょう。実際、Linuxほど複雑な問題は世の中にそうはないので、大抵はあんな厳しい制約はいらないのかも
ふつうDBはDBの世界だけで完結しているべきでアプリの都合なんか関係無いはずなのだけど、往々にして密結合になっているしアプリのデータの入れ物としてしかDBを使わないなら外部キー制約は邪魔って話かしら。
外部キー制約は運用上の障壁になるだけでなく整合性を守る仕組みとしては力不足すぎる システム全体のことを考えたとき、不変条件はアプリケーションにエンコードせざるを得ないのだからそちらに寄せるほうが合理的
そして、find_and_delete_orphan_data.shなんかを作って、cronで回す羽目になる
データ整合性が壊れたまま運用続けてスキーマが腐れているシステムの運用保守をやったことがあるかどうかで意見が異なる気がしている
「制約はアプリの責務」って考え方には共感。DBでも担保しておくのはアリだけど二重管理だし、開発中にテーブル作り直したり関心のあるテーブルにだけ雑なデータ入れようと思ったら制約にかかったり発狂しがち
仕組みとしては良いんだけど、もっと迅速に参照・操作できる標準的なGUI/CUIがあればいいなとは思う。整合性はトランザクションで保証するというのは全面的に賛成ではないけど経験的な実感としては一理ある。
アプリコード側の厳密性をそこまで信頼できる？って言われると、自分は無理。（ゴンドラ作業するときに、「安全確保はゴンドラ側の責務でありフルハーネスは二重管理で無駄」とか言わないじゃん
“システム全体のことを考えたらアプリに不変条件を記述することになるし、そのとき外部キー制約の出番はないよね”
それでも外部キー制約は必要ない / #fk_night でしゃべってきました
blogged
外部キー制約、正規化を使って設計する人にとっての強い味方って感じなので、そうでない人にとっては無用の長物というのは、それはそうって気がする
FK不要論は定期的に燃えるけど、実務で整合性ぶっ壊れた時の絶望を知ると外せなくなる
"ACIDで言えば、A（原子性）D（持続性）には強く期待していますが、C（一貫性）は別の機構で守るべき" / 業務上の「整合性」とRDBの「整合性」にはギャップがあって不便だよね、という意味では同意。
システムを保守していると外部キー制約違反のバグとかよく遭遇するし、業務システムだとテーブル数が数百とかあって色んな人がスポットで保守に関わるから、個人的には制約付けた方が良いんじゃないかと思います
個人的には理解できる。薦めるかというとうーん
“外部キー制約は運用上の障壁（スキーマの変更を阻害する、パーティショニングできなくなる）になるだけでなく、整合性を守る仕組みとしては力不足すぎる。不変条件はアプリ側に寄せるほうが合理的。”
リレーショナルモデルが力不足って、リレーショナルモデルを理解してないだけではなかろうか。
型やテストと違って本番環境にも確実に影響が出る、と考えると理解/説明し易いかも。
ルールベースの運用は守らない者が現れた時にダメージがでかいので制約ベースが安全です。
“単に運用がつらいから制約を弱めようという話をしているのではなくて、システム全体のことを考えたらアプリに不変条件を記述することになるし、そのとき外部キー制約の出番はないよね、という風にご理解いただけ”
webのバックエンドにある時の相性の話？
多層防御というか多層障害発生対策は全然ありで、コスパも良い方かなと思う。コストには速度低減も含めたうえで
データベース設計でシステム全体の整合性は保てないはわかるけど、アプリの条件がどうあれ外部結合の整合性は守られないと怖いよね。 アプリケーション層とデータ層の話を混ぜ返しているように見える。
設計上では必要でも実務では邪魔に感じてしまう。そんな外部キー制約。
そのテーブル群を使って開発してるのが一つのチーム、一つのアプリ群ならそうかもしれないっすね
クリーンアーキテクチャとかではそうだよね。DBを気にしてモデリングなんてしないからな。
DB制約がドメイン制約として不十分なのは同意！！！！！！でも！！！！両方あってもいいよね！！！！！！
アプリ通さないこともあるしバグもあり得るからな。のり代程度でも入れといた方が良い
テストデータ作りにくいんよな
外部キー制約サポートがなかった時代からの古株のRailsユーザーが言いそう。
sqlはStructured Query Languageの略で、queryは質問、疑問、問い合わせといった意味。つまりReadに特化した言語。Writeに特化したspl(Structured Post Language)を作ろう。
削除するときに外部制約があるとかなりめんどい
こういう人が必要としているのはRDBではないのだろうな
まぁチームで認識あってればどっちでもいんじゃね。
外部キー制約は面倒は確実に発生するのに、それによって守れるものがどの程度あるかというと、うーん、だからなぁ……。
この手の意見の不一致ってシステムの種類、規模、状況次第で、そこを揃えない議論は無意味 。業務システムならバッチでどうとでもなるし、C向けシステムみたいに大量のリードや更新を同期処理するなら無理だろう。
ソフトウェアはバグるから絶対に壊れたデータは入ってくる。それを抱えたまま運用するのって長いことソフトウェアエンジニアやってもしんどい。それが少なくなるなら多少のめんどくささは許容する。
“より悪いことに、保証が極めて弱いことで知られる "インターネット" を通してやりとりすることになります。” ？？？
「address = null のユーザーは商品を注文できない」は「DDLの制約」として表現可能なトリガで保証できます。なおアプリ側に集中させてDB側を単純化する、という考え方があり得ること自体は理解します。
ON DELETE CASCADEとかは使わないってことなのか
外部キー制約は運用負担で整合性表現が弱く、DDL（CREATE TABLE）やMySQLではStripe等の分散ケースを守れないため、アプリに不変条件をエンコードすべきと論じます。
外部キー制約を付けるとデータのストア順に制約が付くのだが、一括操作系のツールがそれに対応していないとハマるという。で、それで得られる利点は外部キーがあればその先もあるという保証だけなのが…
すべてを外部制約で解決できないからって、外部制約が要らないことにはならないんじゃないかな
all or nothingではないはずのものを「益がない」などと断定してしまうところがダメなのではないだろうか。益がないはずはないんだよね、トレードオフなだけで
登壇内容を見てないのであまり強いことは言えないし、少なくとも自分より優秀な人なのでそれなりの運用や意図があってやってることはわかるけど…それでも外部キー制約は必要だと俺は思う。運用次第なのかなぁ
外部キーの役割は、アプリ側で実装するのが良いよね
支持します。FKは人類にはまだはやい。DBはもうそろそろ自由に羽ばたけ。リレーショナルから解放されろ。もう30年以上まえからオブジェクトDBとかあるのになぁ
PHPer臭い
外部キーが完全ではないからと言って、存在するメリットを大きく上回るデメリットがない限り、受け入れて利用するだけでしょう
mysqlでマルチテナントの場合、異なるテナントに紐づくのはアプリで整合性担保しないといけないので気休め程度にしかならんのでは。とは思う。けどまぁ必要ない。とは思わないかな。
外部キーはとりあえずDB定義見ただけで理解できるメタデータ定義でもあるので複雑なシステムなら必須だと思う。アプリで定義した制約は簡単に見れないでしょ？
人間が間違えないなら必要ない機能。外部キーを使うことで増加する計算コストを抑える何かがあればよい？
キー制約が最後のガードになるからある方が良い派
LinuxにRustはいらないってのと似てますね。それで問題ないなら確かにいらないんでしょう。実際、Linuxほど複雑な問題は世の中にそうはないので、大抵はあんな厳しい制約はいらないのかも
ふつうDBはDBの世界だけで完結しているべきでアプリの都合なんか関係無いはずなのだけど、往々にして密結合になっているしアプリのデータの入れ物としてしかDBを使わないなら外部キー制約は邪魔って話かしら。
外部キー制約は運用上の障壁になるだけでなく整合性を守る仕組みとしては力不足すぎる システム全体のことを考えたとき、不変条件はアプリケーションにエンコードせざるを得ないのだからそちらに寄せるほうが合理的
そして、find_and_delete_orphan_data.shなんかを作って、cronで回す羽目になる
データ整合性が壊れたまま運用続けてスキーマが腐れているシステムの運用保守をやったことがあるかどうかで意見が異なる気がしている
「制約はアプリの責務」って考え方には共感。DBでも担保しておくのはアリだけど二重管理だし、開発中にテーブル作り直したり関心のあるテーブルにだけ雑なデータ入れようと思ったら制約にかかったり発狂しがち
仕組みとしては良いんだけど、もっと迅速に参照・操作できる標準的なGUI/CUIがあればいいなとは思う。整合性はトランザクションで保証するというのは全面的に賛成ではないけど経験的な実感としては一理ある。
アプリコード側の厳密性をそこまで信頼できる？って言われると、自分は無理。（ゴンドラ作業するときに、「安全確保はゴンドラ側の責務でありフルハーネスは二重管理で無駄」とか言わないじゃん
“システム全体のことを考えたらアプリに不変条件を記述することになるし、そのとき外部キー制約の出番はないよね”