テクノロジー

論理削除の絞り込みはWHERE句でやるな

1: ledsun 2025/11/21 19:49

(速度はおいておいて、論理条件だけみたら)parents.deleted_at IS NULL OR children.deleted_at IS NULL で検索したかった話なのかな?

2: punychan 2025/11/21 20:07

parents側の論理削除はここでは無関係だね。LEFT JOINする右側テーブルで論理削除されたレコードをないものとしたければ、JOIN時に条件つけろということ。

3: tatchimee 2025/11/21 20:16

これハマったときあったなあ。理想的には論理削除なしがいいけど、仕方ないときはビュー作るかな。

4: Niemand 2025/11/21 20:25

そもそも、where句の書き方がおかしいだけ。性能はオプティマイザ次第だが論理削除で isnull を使う設計もおかしい。

5: mcq 2025/11/21 20:52

WHERE句っていう文法の問題じゃなくて、子テーブルのフィルタリングとJOIN演算の適用順序を意識する必要がある、という話

6: mak_in 2025/11/21 21:58

個人的には、論理削除のように、毎回必ず同じwhere条件をつけるものは、テーブルを分けるように設計してる。アーキテクトとしては、いつか誰かがやらかす可能性のある設計はできるだけ潰しておきたいところ。

7: n_231 2025/11/21 22:17

具体的なケースの具体的なクエリが無いのでアレだが、where 区でもnot exists ちゃんと書けば済む話では? 論理削除チェックにnull使ってるのも原因か。普通にflagならこんなややこしいことにならない。

8: hdampty7 2025/11/21 22:27

not existsを使うようになって減ったけど、よくやる。よくSQL書いてるときは問題ないんだけど、書いてないと忘れる。

9: turanukimaru 2025/11/21 22:33

LeftJoinだと親があって子がないレコードは見えるけど論理削除した子供を持った親は見えない、という話か。Join条件はできる限りJoinに書く派なのであえて意識したことはなかったな。

10: kumoha683 2025/11/21 22:39

IS NULLでしか論理削除が判定できない データベースの設計がおかしいのでは?

11: lainof 2025/11/21 22:45

Viewを使えみたいな話かと思ったら、そもそも論理削除に限った話じゃなかった。

12: nojimage 2025/11/21 22:53

論理削除は窓から捨てろ。話はそれからだ

13: mohno 2025/11/21 22:56

そりゃ、LEFT JOINなのにchildrenテーブルをparentsの抽出条件に入れちゃダメ、という話なのでは。「不具合」というより仕様というか。「親テーブルの絞り込みはWHERE句で大丈夫です」

14: kadzuya 2025/11/21 23:03

Gemini "「初学者向け:SQLの評価順序におけるハマりどころ」として書き直すべき内容ですね" と言う感じで社内向けには良い注意喚起だけど公開する内容としては技術ブランディング的にマイナスではと心配に…他人事なが

15: diveintounlimit 2025/11/21 23:04

みんなだいすきゴミ箱機能。