2020/08/09 21:26
mojimojikun
こういうの、夏場に読むと背筋が寒くなっていいのかもだけど……
2020/08/10 01:18
Nfm4yxnW8
ファンクションDB以外は経験あり
2020/08/10 03:31
yug1224
1つ目から親近感
2020/08/10 07:52
emerada
FKなんていちいち付けねーお（ ＾ω＾）
2020/08/10 08:19
tagomoris
この記事はn＋1クエリはダメだということを示しているのでは
2020/08/10 08:28
awawann
ほう
2020/08/10 08:30
pascal256
個別の内容に対しては意見が異なる所もあるけど総じて良記事。しっかり考察されてるし、解法もちゃんと提示してある。振り返る良いきっかけになったし。
2020/08/10 08:44
takeag
外部キーつけない派の人たちへ、つけなかったことによってバグや障害を一度も引き起こしたことがないのか、と聞いてみたい。 自分は外部キーの貼りミスで、テスト段階で気付けてホッとした経験ありまくり。
2020/08/10 08:58
ludwig125
昔見たツールは、DBの作りが悪くて、必要なデータを取るのにクエリを結合しまくって合計2700行くらいのsqlを1リクエストごとに発行してた。webツールなのに1リクエスト処理するだけで数分かかってた
2020/08/10 09:05
machida77
本当にあった怖い話
2020/08/10 09:22
perl-o-pal
テストチューニングの逆パタンで、業務量増加の見積もりがゆるすぎてストレージの99%が空いてるDBはみたことがある。//なのに、ビジネスの失敗を認めず「ストレージ追加しましょう」と提案するSIer。
2020/08/10 09:27
lapk
外部キー嫌いのエンジニアって意外といるんだよね。この前も紐付け先のテーブルのレコードまで削除されるからダメな場合があるとかわけわからん理由でバズってたし。ON DELETE SET NULL 使えよ。これね ur0.work
2020/08/10 09:31
obatakanae
一つの意見として聞いておこうという感じ。 ただ、Rの意味はこれであってるのか…？
2020/08/10 09:37
programmablekinoko
外部キーの設計の巧妙さを知ると、素直に使おうと思えてくる /ステートフルDBは結構使われているイメージ。 割とWebアプリケーションフレームワークでセッションやクッキーの値をRDBに保存してたりする
2020/08/10 09:40
sh2ysd
RDBのRはテーブル間の関連のことではないと何度言えば
2020/08/10 10:14
regularexception
具体例書いてくれないとわかりづらい
2020/08/10 10:25
hogeaegxa
ロジカルクエリーには現在進行形で苦しめられてる。ORDER BYすらCASEで分岐してるぐらいの分岐と結合の嵐で、SQLのUT書くなんてことやってるわけもなく手出しできん。
2020/08/10 10:25
glizmo
外部キーつけない人とか今まで出会ったことないんだけど。教育を全く受けてない人がいるの？
2020/08/10 10:32
oakbow
外部キー嫌い、いるね。フレームワークによっちゃFKの対応が未熟で使いづらいってのは確かにあったんだけど、それ以外じゃ単にFK分かってないだけだなと思うことがほとんど。
2020/08/10 10:47
Futaro99
俺はデータベースで無用にロジックを持ちたくない、整合性はアプリケーションが担保すべきという理由で長らく外部キー張らない派だった。（当然無理だった）
2020/08/10 10:51
Shinwiki
リレーションの意味ってこれであってたっけ？
2020/08/10 11:01
diveintounlimit
全部サラッと読んだが正しさを振りかざして現場の事情を考えないタイプかな。あんまり一緒に仕事したいとは思わないな。
2020/08/10 11:03
cl-gaku
ベテランの脳が外部キーに対応してないのでついてない
2020/08/10 11:33
nekochiyo
外部キー的カラムを作らないのか、外部キー制約を設定しないのかで話が全然違う
2020/08/10 11:40
rck10
大体違和感はないけど、"テスト環境をケチるな" は同意できない。お客さんの財布都合もあるので、エンジニアの正しさだけで実現できるものではない。
2020/08/10 11:43
circled
外部キー嫌いのエンジニア → Yahoo IDのことかな？
2020/08/10 11:46
bebit
あの意味のわからないテーブル命名規則は「囚人番号テーブル」って呼ぶのね。なるほど。
2020/08/10 11:48
daishi_n
今はクラウドで本番環境と同等のテスト環境をすぐ立ち上げられるし、ケチる理由はだいぶ減ったけどね
2020/08/10 11:50
axjack
そっか、こういう時のDBってアプリにとってのDBだからDWHとかBIの感覚で見ちゃいけないんだな。スタースキーマとかディメンションが出てこないわけだ。
2020/08/10 11:56
shikiarai
第一正規形くらいなら外部キー良いんだけど、一体第n正規形なんだ……みたいな正規化をされた上で外部キーバリバリ張ってあるとデータ払い出しの時に泣きそうになる。どっちにしろ開発部隊のエゴを押し付けられるが
2020/08/10 11:58
lethli
RDBだとテーブル自体をRelationと呼ぶのでテーブル間の関係のことではない。スキーマ周りはシステムのどのレイヤーに責任を持たせるかの設計が出来てれば必ずしも間違ってるわけではないのでは、という気もする
2020/08/10 12:11
kyuuuuuji
外部キー無しは「本来機械が考慮してくれること」を人間が自分でやらないといけなくなっている感じがして好きじゃない。そしてテーブル数が増えてくるといちいち覚えてらんない
2020/08/10 12:15
takopons
DBテーブル設計のアンチパターンみたいなもの。
2020/08/10 12:23
at_yasu
R無し…？外部キーかしら。きっと MyISAM 使ってるんだよ…
2020/08/10 12:42
itotto
外部キーは基本的に使わないな。使いたくなることもなかった。
2020/08/10 12:54
watarux
外部キーは使った方がいいと思うけどどこの会社いっても設計書がそうなってるからなあ・・・SIerなんて95%ぐらいがAccessとかPowerPivotで十分なレベルでしかRDB使ってないよね
2020/08/10 12:58
nunulk
ブコメ、外部キーに対する考え方が色々で興味深い
2020/08/10 12:59
xenon_abe
ロジカルクエリーって何だ? チマチマとフェッチしてごちゃごちゃやるよりもSQL一発のほうが速いし構造も理解しやすいこともある。総合的に判断が必要。ただ遅いコードは(何で書かれていようが)死。そこは同意。
2020/08/10 13:26
ryunosinfx
KVSなのかRDBを使うかは置いといて、まあ半分やらかしだけど、この人サーバレス環境のステートレスとか知らなそう。外部キーはDB管理者の専任者を置ける規模レベルじゃないと手におえんよ。
2020/08/10 13:26
tobigitsune
なんで張ってあるリンクを読まずに内容についてコメントできるんだろう
2020/08/10 13:35
prograti
外部キー制約を使うことに異論はありませんが、ロックは意識すべきですね。
2020/08/10 14:01
Hiro_macchan
メモ
2020/08/10 14:09
homarara
ロジカルクエリーって呼ぶのかそういうの。呼び出し元がvbsとかで複雑な事ができなかったりすると、sqlでできる部分はsqlでやってしまわないと呼び出し元がえらい事になるケースもあるんだよなあ。
2020/08/10 14:40
kanehama
外部キー制約つけたら垂直分割の時大半そうだけどどうなんやろ？
2020/08/10 14:55
tettekete37564
マスタ系だけ普通のファイルになっているせいでリレーション処理を都度自前で書かなくてはいけないゲロ設計。何のための「R」DBMなのかさっぱりわからない。むしろ全部ファイルなら一気にRDBMに移行できる様に書けるの
2020/08/10 14:57
Jinhachi
タイトル見るだけで胃がキュッとなった
2020/08/10 15:27
nakag0711
一通り見たが概して初級者レベルの間違いや思い込みが多い。まず本当に正規化が分かってるのか疑問
2020/08/10 15:36
quabbin
なんか全体的に変だなぁ…と少しの間もやもやしたけど、ふと思った。これ、モデル設計とアプリ設計が混ざっている上、内部設計と外部設計までもがまざっているな。それがために、結論が変なんだな。
2020/08/10 15:41
laskatan
やらかしたかも委員会的にはやらかしたとは言えないものが多数混ざってますね
2020/08/10 15:46
hylom
高尚な話だった
2020/08/10 15:48
iww
外部キー制約はつけたことがほぼ無い。 たぶん良くないことだと思うけど、思うだけで行動に移していない
2020/08/10 16:07
rryu
名称が完全独自な割にどういうものを問題としているのかがいまいち分からない。「見えない削除フラグ」は設計というよりフラグ未更新のバグっぽいし…
2020/08/10 16:17
kae1990
外部キー制約は要らないケースが多いと思うぞ（製品によるが）。そもそもユーザーがDeleteできる設計に問題があったり、ユーザーが手動で操作すべきでないデータを操作できたりと、仕様に誤りがある場合が多い
2020/08/10 16:28
iekusup
ほー。
2020/08/10 17:11
kakei-akihiko
外部キーは制約に反するデータを登録できないこと自体よりも、参照先のレコード削除時に一緒に消えてくれる機能が便利でいい。
2020/08/10 17:31
weakref
未熟ゆえの思い込みが多く突っ込みどころ満載
2020/08/10 17:35
for-my-internet-demo
ddd派の言い分は同集約だけ貼る、だったような。それはいいとして全く貼らない派のロートルが他のアーキテクチャやアプリのレイヤ構成はしっかりしてる人間かというと経験上まったくそんなことはないんだが
2020/08/10 17:36
pavlocat
よくまとまっててためになる（外部キー制約無し派が思いのほか多くて驚いてる。整合性はアプリで解決してるんですか…）
2020/08/10 17:39
metatrading
言いたいことは分かるんだが、いくつか基本となる考え方（正規化とかSQLを作るうえでの集合の考え方とか）へつなげられるはずで、よその考え方のつまみ食いから昇華できていないような印象が強い。
2020/08/10 17:46
kagehiens
外部キーによる連動削除(またはNULL埋め)は、むしろ物理削除禁止をアプリに実装した方が良いケースばっかりに思うんだが、そうじゃないケースを誰か例付きで解説してくれる人は居たりしないかな。
2020/08/10 17:59
EngineerYtr
あとで読もう。
2020/08/10 18:00
NetPenguin
RDBのRを外部キーによる参照だと勘違いしていそう。リレーショナルの事で、テーブルの事だったはず。複数の属性をひとまとめに扱えるようにしている。
2020/08/10 18:10
fujiten3
外部キーを使わないということはデータ整合性に関してのロジックをアプリケーション層で'確実に'担保しなければならないということ。不整合の代償を払う覚悟があるものだけが到着できる境地。あるいは無謀。
2020/08/10 18:25
nippondanji
RDBのRはリレーションシップじゃないんだなコレが。リレーショナルモデルのことやで。
2020/08/10 19:07
minoton
このRは、Relationship（意味的にはReferential integrity ＝参照整合性でもOKか)で通じる気が
2020/08/10 19:10
napsucks
FK制約をつけるとアプリ側でエラートラップしないといけないもん。アプリに問題がないならDB側で制約は要らんでしょ(暴論
2020/08/10 20:01
fusionstar
DB 設計ではない話が散見されますがそれは…。
2020/08/10 20:05
hiby
> 外部キーを付ける　FKは一生そのDBの面倒みる覚悟ならええよ。そうで無いなら単なる理想論。あとからパフォーマンス事故を起こしてその時現場にいた人が爆死する。そしてまた1人FK嫌いが生まれる。
2020/08/10 20:19
miluru
一緒に仕事したくない系エンジニアだ
2020/08/10 20:31
tpircs
一応全部読んでみたけど、不勉強な思い込みが多かったので誰かに教えてもらうとか学びなおすとかしたほうがよさそうって思った。なお、自分がみたやらかし設計はXMLがそのまま入ってて、検索の都度パース地獄。
2020/08/10 20:44
noseld
実際に見たひどい現場に向けて書いたってのは分かるんだけど、問題の抽象化の方向性に違和感を覚える。そういう意味で、あまり初心者に読んで欲しくない記事だと感じてしまった。問題提起としては面白かった。
2020/08/10 21:55
t_f_m
あとで
2020/08/10 22:09
buhoho
"ステートフルDB"これよくわからなかった。DBって永続性もそうだけど、動的な書き換えを安全に行えるのが利点の一つだと思ってる
2020/08/10 23:30
tumo300-500
どの内容もちょっとずつ突っ込みどころがあって、これは狙ってやっている説
2020/08/11 00:48
onesplat
外部キー付けられるくらいの規模のシステムしか作ったことないなんて幸せですねとしか。素人の声がデカい問題って何とかならんのかね
2020/08/11 00:51
arx0balest
FKのないRDBって、パフォーマンスの悪いNoSQLでは（暴論）
2020/08/11 00:59
akahigeg
全体的に説明が冗長な気がする。
2020/08/11 01:21
tmtms
具体例がないとちょっと理解しずらいかなー。はてブのコメントに外部キーつけない派が結構いておどろくなど。
2020/08/11 01:29
eerga
外部キー使わずにアプリだけで対応出来ていた派です(すごく複雑なものは作っていない)。むしろ外部キーとindex付けてselectとinsertガンガン投げたらdead lockしたから結構調べるはめになった。
2020/08/11 06:29
poTracy
でかいテーブルもやりすぎ正規化も、抑々その前の概念設計でコケてる印象。