本当にあったやらかしDB設計①【R無しRDB】 - Qiita

どうも、IT業界は4年目だけど開発はあんまりやったことがなかった人です 独学でDBとアプリ周りを勉強して最近開発現場へと行くことになったのですが、僕でもわかるようなやばいような事がかなりゴロゴロあって唖然とする毎日です(運が良いのか悪いのか…) 今日はそんな中の一つを紹介したいと思います これには本当にびっくりしました どういうことかというと、外部キーをひとつも使ってなかったのです 分析系DBなのかと思いきや調べたり聞いたりして確認したところがっつり処理系、しかもコアな部分…ｗ データの不整合を許せない部分なのに外部キーを全く使っていないという、アンチパターンというか呆れパターンというか… 何が悪いの？？ そう、まずはここから説明していきます 同じことを繰り返さないようにするための記事なので、ただバカにするだけだと意味ないですからね 1980年代～1990年代くらいに過激な生き残りをかけた

[diveintounlimit]

以前は某イルカが外部キー付けるとクソ遅かったんで外部キー付けないのを引きずるのは分かる。今でも外部キー制約がネックになって可及的速やかに消したい大量のレコードが消せないことがままあるので今でも分かる。

[fai_fx]

ユニーク制約、ノットヌル制約は便利すぎて必須だけど、R無しは無しの方がテーブル間の独立性が担保されて運用上は便利なことが多い。

[nakag0711]

外部キーでなく外部キー制約。外部キーは概念なので常に存在する。外部キー制約を付けないことによる楽さもないこともないので一概に付けた方がいいとは言えない気がするな

[nmcli]

最初は外部キー制約でガッチガチに固めるの好きだったけど、障害時とか仕様変更時とか邪魔なので徐々に使わなくなった。逆に外部キー制約をアテにした設計をしないことのほうが大事で。

[Wafer]

joinなんつこてたらソシャゲの９０％は動かなくなるんじゃね？

[n593977]

内容や用途によって外部キーをあえて付けない設計もアリだと思うけどね

[ys0000]

外部キー制約なしのRDBは作ったことあるなぁ。ホストからCSV送られてくるのを取り込んで二次加工するのが主だったからバッチ取り込みで止まるとかが怖くて。登録データに責任を持てない時にはつけない事もある。

[tpircs]

外部キー制約を使わないのをやらかしとは言わないで欲しいかな。

[yamadadadada2]

orマッパで関係を記述できるので外部キーは刺さないってのはよくやる手段かと思ってた。運用で想定外なことが起きたときに外部キーが邪魔てのはよくあるので

[nekoluna]

ほえー

[miyataro32]

RDBのRが指す関係(リレーション)はテーブルのデータ構造のことであってテーブル間の関係(リレーションシップ)とは別物だよ

[Iridium]

今やってる開発でも外部キーはない。確か消したいレコードが消せなくなるという理由だったような

[masa_w]

外部キーがないからrelationがないというわけではないんだが。学びたての頃は自分も原理主義者だったけど、外部キー制約は設計の変更に弱いんよね

[dodecamin]

オライリーのエンタープライズアーキテクチャー本にあるようなDB側で防ぐという考え方は私は懐疑的。制約の前提条件がビジネスの変更で無くなる事も考慮しないといけない。

[boomerangj]

テストやオンラインでのデータ移行や一括処理とかで邪魔な時あるんだよな。

[rizmhate]

MyIsamだとそもそも外部キー制約つかえないよね