これスマートな気がするんですよね。削除日時みたいに、削除テーブル側にだけ必要な列もあるでしょうし
“論理削除は、実際に運用していくとツラい。元を辿ると、ライフサイクルの異なる状態を 1 つのテーブルに同居させているところが原因では。 在籍中のユーザーと退会済みのユーザーでは、扱う情報も参照頻度も違う”
なるほどPartial Indexか
いいと思う
論理削除は削除じゃない！！！！！RemovedXXXというエンティティに状態遷移してるんだ！！！！！！！！
削除済みかどうかに関係なくソートしたい場合はパフォーマンスに影響しないのかな、状態別テーブルの方。
とても良いと思います。
“状態を判別子として外部キーに組み込んでしまうと、トリガーなしで保証できるようになります。” なるほど
参照している側は常に2つのテーブルを見ることになったりしないんだろうか。両側を同時に見たいというニーズが少ないのならいいんだけど。あとやはりテーブルの総数は増えるね。
DBの話というよりモデリングの話では。履歴を残したいっていうのがドメインの欲求なのであれば適切にモデリングをする。そうするとDBは自然に決まる。それをサボると辛いのはそりゃそうである。
（あとで読む）IO起因による応答速度の低下がなければ賛成ではある理屈
こいつ馬鹿なのかなと思う。テーブルごとに都度考えればよい話をなんでソフトデリートをやめる設計とか言い出すの？大体、論理削除と状態管理は別の話だろうに。削除はon/offで状態管理というよりフラグだろ。
この手の話で毎回思うのだけど「クエリの度に〜を書く必要があり」については「書けば良いのでは」としか思えないのだよなぁ
契約状態、休眠状態、解約(未集金無し)、解約(未集金あり)...と状態が増えていったらその都度テーブル増やすのかな
論理削除をやめて状態をテーブルで分けるDB設計
これスマートな気がするんですよね。削除日時みたいに、削除テーブル側にだけ必要な列もあるでしょうし
“論理削除は、実際に運用していくとツラい。元を辿ると、ライフサイクルの異なる状態を 1 つのテーブルに同居させているところが原因では。 在籍中のユーザーと退会済みのユーザーでは、扱う情報も参照頻度も違う”
なるほどPartial Indexか
いいと思う
論理削除は削除じゃない！！！！！RemovedXXXというエンティティに状態遷移してるんだ！！！！！！！！
削除済みかどうかに関係なくソートしたい場合はパフォーマンスに影響しないのかな、状態別テーブルの方。
とても良いと思います。
“状態を判別子として外部キーに組み込んでしまうと、トリガーなしで保証できるようになります。” なるほど
参照している側は常に2つのテーブルを見ることになったりしないんだろうか。両側を同時に見たいというニーズが少ないのならいいんだけど。あとやはりテーブルの総数は増えるね。
DBの話というよりモデリングの話では。履歴を残したいっていうのがドメインの欲求なのであれば適切にモデリングをする。そうするとDBは自然に決まる。それをサボると辛いのはそりゃそうである。
（あとで読む）IO起因による応答速度の低下がなければ賛成ではある理屈
こいつ馬鹿なのかなと思う。テーブルごとに都度考えればよい話をなんでソフトデリートをやめる設計とか言い出すの？大体、論理削除と状態管理は別の話だろうに。削除はon/offで状態管理というよりフラグだろ。
この手の話で毎回思うのだけど「クエリの度に〜を書く必要があり」については「書けば良いのでは」としか思えないのだよなぁ
契約状態、休眠状態、解約(未集金無し)、解約(未集金あり)...と状態が増えていったらその都度テーブル増やすのかな