これスマートな気がするんですよね。削除日時みたいに、削除テーブル側にだけ必要な列もあるでしょうし
“論理削除は、実際に運用していくとツラい。元を辿ると、ライフサイクルの異なる状態を 1 つのテーブルに同居させているところが原因では。 在籍中のユーザーと退会済みのユーザーでは、扱う情報も参照頻度も違う”
なるほどPartial Indexか
いいと思う
論理削除は削除じゃない！！！！！RemovedXXXというエンティティに状態遷移してるんだ！！！！！！！！
削除済みかどうかに関係なくソートしたい場合はパフォーマンスに影響しないのかな、状態別テーブルの方。
とても良いと思います。
“状態を判別子として外部キーに組み込んでしまうと、トリガーなしで保証できるようになります。” なるほど
参照している側は常に2つのテーブルを見ることになったりしないんだろうか。両側を同時に見たいというニーズが少ないのならいいんだけど。あとやはりテーブルの総数は増えるね。
DBの話というよりモデリングの話では。履歴を残したいっていうのがドメインの欲求なのであれば適切にモデリングをする。そうするとDBは自然に決まる。それをサボると辛いのはそりゃそうである。
（あとで読む）IO起因による応答速度の低下がなければ賛成ではある理屈
こいつ馬鹿なのかなと思う。テーブルごとに都度考えればよい話をなんでソフトデリートをやめる設計とか言い出すの？大体、論理削除と状態管理は別の話だろうに。削除はon/offで状態管理というよりフラグだろ。
この手の話で毎回思うのだけど「クエリの度に〜を書く必要があり」については「書けば良いのでは」としか思えないのだよなぁ
契約状態、休眠状態、解約(未集金無し)、解約(未集金あり)...と状態が増えていったらその都度テーブル増やすのかな
primary idはさらに別テーブルで一元管理したりするのかな (どんどん複雑化ｗ) オブジェクト数でライセンス料金が変わるSalesforce界隈では絶対に無理な設計手法ですね…(´・ω・`)
ボク、それいいね！消えたんじゃなくて隠れたなの？かわいいにゃ！
論理削除はインデックスもしずらく、アンチパターンと捉えてる
ビューでいいや。whereを書き忘れることもない。サービスによるけどユーザーテーブルの削除ってそんなにレコード数増えないでしょ。適切にインデックス張ってればinner joinよりパフォーマンスも出るでしょう
すでに指摘が入っているけどこの手法は「クエリの度に〜を書く必要があり」の解消方法ではない。別の動機でこの設計を採用することはあるだろうけど...
現実世界も削除という行為を追加してるだけだし
もはや論理削除を受け入れるほうがスマートまである
ケースバイケースだけど、状態の表現はデータモデルを分けるのではなくて、ドメインモデルを分けることが多いかな
状態が有効と削除しかないようなデザインならテーブルをわけたほうがメリットは多いよ。ライフサイクル混ぜるなというのも納得。ただ状態が複数あるなら別のアプローチとる。パーティションやビュー使えばいいのでわ
ワイは支持する。
履歴をDBっても良くなったのか。いい時代になったな。
この手の議論で忘れ気味なのが、「近年のスキーマ変更は、昔に比べてやりやすくなった」ということ。性能限界が待っているのなら、その時にスキーマ変更すればいいという手段を忘れてはならないということだと。
外部キー制約下で状態別テーブルを実装できるという無難な技術論と、だから常にそう実装すべきという極端な設計論を、記事も一部ブコメも混同しているように見える。
関係ないけど、退会したのに個人情報が消えない論理削除はユーザの理解が得られるのかな？コンプライアンス的な意味で
ブコメをまとめてもらったら視点が増えた
×退会状態テーブル、〇全会員テーブルと現行会員テーブルと（必要なら）退会会員テーブルを作る。RDBは状態を管理してるんじゃない。リストを管理してるんだ。時間により変わるデータを管理するのには全く向いてない
んー。古いインフラが前提になっているからだろう。話がややこしくなってる…。
はてブコメントで議論が巻き起こってるが、削除ユーザテーブルに分けるのは、あるよね
“両方のテーブルに同時に入らないことを保証する” これは保証できても、user_accountsにだけデータが存在する不整合は排除できなさそう。
こっちも読んでみてほしい。 https://zenn.dev/ksuzumura/articles/a2301d4dfdc5c4
論理削除をやめて状態をテーブルで分けるDB設計
これスマートな気がするんですよね。削除日時みたいに、削除テーブル側にだけ必要な列もあるでしょうし
“論理削除は、実際に運用していくとツラい。元を辿ると、ライフサイクルの異なる状態を 1 つのテーブルに同居させているところが原因では。 在籍中のユーザーと退会済みのユーザーでは、扱う情報も参照頻度も違う”
なるほどPartial Indexか
いいと思う
論理削除は削除じゃない！！！！！RemovedXXXというエンティティに状態遷移してるんだ！！！！！！！！
削除済みかどうかに関係なくソートしたい場合はパフォーマンスに影響しないのかな、状態別テーブルの方。
とても良いと思います。
“状態を判別子として外部キーに組み込んでしまうと、トリガーなしで保証できるようになります。” なるほど
参照している側は常に2つのテーブルを見ることになったりしないんだろうか。両側を同時に見たいというニーズが少ないのならいいんだけど。あとやはりテーブルの総数は増えるね。
DBの話というよりモデリングの話では。履歴を残したいっていうのがドメインの欲求なのであれば適切にモデリングをする。そうするとDBは自然に決まる。それをサボると辛いのはそりゃそうである。
（あとで読む）IO起因による応答速度の低下がなければ賛成ではある理屈
こいつ馬鹿なのかなと思う。テーブルごとに都度考えればよい話をなんでソフトデリートをやめる設計とか言い出すの？大体、論理削除と状態管理は別の話だろうに。削除はon/offで状態管理というよりフラグだろ。
この手の話で毎回思うのだけど「クエリの度に〜を書く必要があり」については「書けば良いのでは」としか思えないのだよなぁ
契約状態、休眠状態、解約(未集金無し)、解約(未集金あり)...と状態が増えていったらその都度テーブル増やすのかな
primary idはさらに別テーブルで一元管理したりするのかな (どんどん複雑化ｗ) オブジェクト数でライセンス料金が変わるSalesforce界隈では絶対に無理な設計手法ですね…(´・ω・`)
ボク、それいいね！消えたんじゃなくて隠れたなの？かわいいにゃ！
論理削除はインデックスもしずらく、アンチパターンと捉えてる
ビューでいいや。whereを書き忘れることもない。サービスによるけどユーザーテーブルの削除ってそんなにレコード数増えないでしょ。適切にインデックス張ってればinner joinよりパフォーマンスも出るでしょう
すでに指摘が入っているけどこの手法は「クエリの度に〜を書く必要があり」の解消方法ではない。別の動機でこの設計を採用することはあるだろうけど...
現実世界も削除という行為を追加してるだけだし
もはや論理削除を受け入れるほうがスマートまである
ケースバイケースだけど、状態の表現はデータモデルを分けるのではなくて、ドメインモデルを分けることが多いかな
状態が有効と削除しかないようなデザインならテーブルをわけたほうがメリットは多いよ。ライフサイクル混ぜるなというのも納得。ただ状態が複数あるなら別のアプローチとる。パーティションやビュー使えばいいのでわ
ワイは支持する。
履歴をDBっても良くなったのか。いい時代になったな。
この手の議論で忘れ気味なのが、「近年のスキーマ変更は、昔に比べてやりやすくなった」ということ。性能限界が待っているのなら、その時にスキーマ変更すればいいという手段を忘れてはならないということだと。
外部キー制約下で状態別テーブルを実装できるという無難な技術論と、だから常にそう実装すべきという極端な設計論を、記事も一部ブコメも混同しているように見える。
関係ないけど、退会したのに個人情報が消えない論理削除はユーザの理解が得られるのかな？コンプライアンス的な意味で
ブコメをまとめてもらったら視点が増えた
×退会状態テーブル、〇全会員テーブルと現行会員テーブルと（必要なら）退会会員テーブルを作る。RDBは状態を管理してるんじゃない。リストを管理してるんだ。時間により変わるデータを管理するのには全く向いてない
んー。古いインフラが前提になっているからだろう。話がややこしくなってる…。
はてブコメントで議論が巻き起こってるが、削除ユーザテーブルに分けるのは、あるよね
“両方のテーブルに同時に入らないことを保証する” これは保証できても、user_accountsにだけデータが存在する不整合は排除できなさそう。
こっちも読んでみてほしい。 https://zenn.dev/ksuzumura/articles/a2301d4dfdc5c4