本当にあったやらかしDB設計シリーズ一覧 - Qiita

本当にあったやらかしDB設計シリーズをまとめてみました SQLアンチパターンで書かれているほど高尚な問題ではなく、もっと初歩的な、でもありがちな問題を取り上げています 初心者を脱出したと思っている人に是非読んでもらい、正しく設計してもらうことを目的としています もしここに載っていないパターンを経験したことのある方がいたら是非教えてください 本当にあったやらかしDB設計①【R無しRDB】 本当にあったやらかしDB設計②【囚人番号テーブル】 本当にあったやらかしDB設計③【ロジカルクエリー】 本当にあったやらかしDB設計④【テストチューニング】 本当にあったやらかしDB設計⑤【第三正規化病】 本当にあったやらかしDB設計⑥【見えない削除フラグ】 本当にあったやらかしDB設計⑦【ステートフルDB】 本当にあったやらかしDB設計⑧【ファンクションDB】 本当にあったやらかしDB設計⑨【文字列日付】

[takeag]

外部キーつけない派の人たちへ、つけなかったことによってバグや障害を一度も引き起こしたことがないのか、と聞いてみたい。 自分は外部キーの貼りミスで、テスト段階で気付けてホッとした経験ありまくり。

[diveintounlimit]

全部サラッと読んだが正しさを振りかざして現場の事情を考えないタイプかな。あんまり一緒に仕事したいとは思わないな。

[tagomoris]

この記事はn＋1クエリはダメだということを示しているのでは

[Futaro99]

俺はデータベースで無用にロジックを持ちたくない、整合性はアプリケーションが担保すべきという理由で長らく外部キー張らない派だった。（当然無理だった）

[oakbow]

外部キー嫌い、いるね。フレームワークによっちゃFKの対応が未熟で使いづらいってのは確かにあったんだけど、それ以外じゃ単にFK分かってないだけだなと思うことがほとんど。

[kagehiens]

外部キーによる連動削除(またはNULL埋め)は、むしろ物理削除禁止をアプリに実装した方が良いケースばっかりに思うんだが、そうじゃないケースを誰か例付きで解説してくれる人は居たりしないかな。

[rck10]

大体違和感はないけど、"テスト環境をケチるな" は同意できない。お客さんの財布都合もあるので、エンジニアの正しさだけで実現できるものではない。

[yug1224]

1つ目から親近感

[kyuuuuuji]

外部キー無しは「本来機械が考慮してくれること」を人間が自分でやらないといけなくなっている感じがして好きじゃない。そしてテーブル数が増えてくるといちいち覚えてらんない

[programmablekinoko]

外部キーの設計の巧妙さを知ると、素直に使おうと思えてくる /ステートフルDBは結構使われているイメージ。 割とWebアプリケーションフレームワークでセッションやクッキーの値をRDBに保存してたりする

[uesima]

データベース

[yuzuk45]

リング（現場）じゃ使用(つか)エねえ・・・

[poTracy]

でかいテーブルもやりすぎ正規化も、抑々その前の概念設計でコケてる印象。

[eerga]

外部キー使わずにアプリだけで対応出来ていた派です(すごく複雑なものは作っていない)。むしろ外部キーとindex付けてselectとinsertガンガン投げたらdead lockしたから結構調べるはめになった。

[tmtms]

具体例がないとちょっと理解しずらいかなー。はてブのコメントに外部キーつけない派が結構いておどろくなど。

[akahigeg]

全体的に説明が冗長な気がする。

[arx0balest]

FKのないRDBって、パフォーマンスの悪いNoSQLでは（暴論）

[onesplat]

外部キー付けられるくらいの規模のシステムしか作ったことないなんて幸せですねとしか。素人の声がデカい問題って何とかならんのかね

[tumo300-500]

どの内容もちょっとずつ突っ込みどころがあって、これは狙ってやっている説

[buhoho]

"ステートフルDB"これよくわからなかった。DBって永続性もそうだけど、動的な書き換えを安全に行えるのが利点の一つだと思ってる

[t_f_m]

あとで

[noseld]

実際に見たひどい現場に向けて書いたってのは分かるんだけど、問題の抽象化の方向性に違和感を覚える。そういう意味で、あまり初心者に読んで欲しくない記事だと感じてしまった。問題提起としては面白かった。

[tpircs]

一応全部読んでみたけど、不勉強な思い込みが多かったので誰かに教えてもらうとか学びなおすとかしたほうがよさそうって思った。なお、自分がみたやらかし設計はXMLがそのまま入ってて、検索の都度パース地獄。

[hiby]

> 外部キーを付ける　FKは一生そのDBの面倒みる覚悟ならええよ。そうで無いなら単なる理想論。あとからパフォーマンス事故を起こしてその時現場にいた人が爆死する。そしてまた1人FK嫌いが生まれる。

[fusionstar]

DB 設計ではない話が散見されますがそれは…。

[napsucks]

FK制約をつけるとアプリ側でエラートラップしないといけないもん。アプリに問題がないならDB側で制約は要らんでしょ(暴論

[minoton]

このRは、Relationship（意味的にはReferential integrity ＝参照整合性でもOKか)で通じる気が

[nippondanji]

RDBのRはリレーションシップじゃないんだなコレが。リレーショナルモデルのことやで。

[fujiten3]

外部キーを使わないということはデータ整合性に関してのロジックをアプリケーション層で'確実に'担保しなければならないということ。不整合の代償を払う覚悟があるものだけが到着できる境地。あるいは無謀。

[NetPenguin]

RDBのRを外部キーによる参照だと勘違いしていそう。リレーショナルの事で、テーブルの事だったはず。複数の属性をひとまとめに扱えるようにしている。

[EngineerYtr]

あとで読もう。

[metatrading]

言いたいことは分かるんだが、いくつか基本となる考え方（正規化とかSQLを作るうえでの集合の考え方とか）へつなげられるはずで、よその考え方のつまみ食いから昇華できていないような印象が強い。

[pavlocat]

よくまとまっててためになる（外部キー制約無し派が思いのほか多くて驚いてる。整合性はアプリで解決してるんですか…）

[for-my-internet-demo]

ddd派の言い分は同集約だけ貼る、だったような。それはいいとして全く貼らない派のロートルが他のアーキテクチャやアプリのレイヤ構成はしっかりしてる人間かというと経験上まったくそんなことはないんだが

[weakref]

未熟ゆえの思い込みが多く突っ込みどころ満載

[kakei-akihiko]

外部キーは制約に反するデータを登録できないこと自体よりも、参照先のレコード削除時に一緒に消えてくれる機能が便利でいい。

[iekusup]

ほー。

[kae1990]

外部キー制約は要らないケースが多いと思うぞ（製品によるが）。そもそもユーザーがDeleteできる設計に問題があったり、ユーザーが手動で操作すべきでないデータを操作できたりと、仕様に誤りがある場合が多い

[rryu]

名称が完全独自な割にどういうものを問題としているのかがいまいち分からない。「見えない削除フラグ」は設計というよりフラグ未更新のバグっぽいし…