昔から思うんだけど、フラグ操作で削除したように見せることを「論理削除」と言うことに違和感。レイヤーを下げれば DB のレコード削除も実装によっては同様だし、ファイル削除もそう。物理削除は全然物理じゃない。
> id:JULY physical delete は永続的に操作対象・参照対象でなくなる。という意味ですがどこか問題ありますか？/ 話がややくしくなりそうなとき、特にFKを貼りたいときはクラステーブル継承にして親に貼るのが一番楽だと思う。
ほとんどのケースは削除時に適切なログを残しておくことでカバー出来ると思ってる。そうでないユースケースがあるときだけ真剣に考えれば良い。
これは部分インデックスで出来る気が（PostgreSQL） / "「アクティブユーザで一意であること」のような制約があるとき、削除レコードも含むため、RDBMSのUNIQUE制約を付与できない"
https://www.sesarju.eu/sites/default/files/webform/annual_conf_2022_contrib/_sid_/talk-directly-to-robinhood.pdf
レイヤードアキテクチャの場合外から見える振る舞いと内部実装を一致させる必要がないのがメリットなのでブコメは何を当たり前のことを言ってるんだ感あるんだけど
いつも思うんだけど、個人情報保護法の観点で見るとユーザ情報の削除ってすげぇむずい。大手サービスで問い合わせしてもまともな回答が返ってこないから多分どこも困ってると思うんだけど...
外部キー制約で削除できないとか、無くても不整合にしたくないときは論理削除ではなく、ログイン不可とか意味のある列にすればいい。unique制約のあるメールアドレスとかは重複しないように更新してたな。
？と思ったが、「テーブル継承」←今どきのRDBMSは（またはPostgreSQLは(?)）テーブルの定義を継承できるのか。知らない世界だったというか、それが“新しい世界”なのかな。SQL Serverには見当たらないけど。
簡潔な設計とクエリにしたい場合が多い／メールアドレスのように「アクティブユーザで一意であること」のような制約 > deleted_atなどの削除フラグとメールアドレスをを組み合わせた複合ユニーク制約を定義すればできる
ビジネスロジックとしてその機能が重要なのであればモデリングするし、そうでないなら永続化層で吸収するだけ。
こないだAIに論理削除ロジック書かせたらsoft_deleteって関数名だった。英語ではそう言うのかな。
基幹系とかだとホント消さない。会計なら赤黒で±0にするし給与なら翌月精算だし。削除フラグよりも履歴（開始日終了日）管理で終了日セットのことが多い。
英語だと物理削除: hard delete、論理削除: soft deleteだからそんな違和感ないんよな、「非可逆削除」「可逆削除」とかの方がいいんじゃね？
条件付きのUNIQUE制約を使えるDBなら付与できる→"「アクティブユーザで一意であること」のような制約があるとき、削除レコードも含むため、RDBMSのUNIQUE制約を付与できない"
論理削除の言葉の定義に違和感あるってマジ？手法の善し悪しは別にして復元可能なら論理削除、負荷なら物理削除という区別でいいのでは？
論理削除？データもボクも消さないで欲しいにゃ。寂しいのは嫌にゃ！
個人情報保護の観点で悩む奴。
このやり方はイミュータブルデータモデルを採用する限り、唯一の方法で、他の選択肢は全くない。判断フローも何もない。そしてイミュータブルデータモデルは優れているので採用すべし。論理削除とか悩む必要なし
ドリルで穴をあけるのが物理削除
退会したユーザー「えぇっ、退会したのに私の個人情報残ってるんですか！？」
物理で消す
I
紙とペンでやれば良いのでは…
RDBみたいに最終的にクエリでデータの見え方を決定するような場合に、テーブルを分けるのは繰り返しの排除くらいしかメリットはないと思ってたけど、こうやって意図を明確にする効果もあるのかと思った
id:mohno ここでテーブル継承は概念的でしかなくて、その実現のために全部1テーブルでタイプ列を持つか、複数テーブルに分けるか、idと共通要素抜き出して参照するかを書いてると思います
論理削除:その人を存在しない人間として扱う。物理削除:その人の存在を消す。 物騒だな。
追記オンリーかつイミュータブルであることが目的化してる？。将来的に何も消さなくて済む時代か…HDDが20MBしかなかった時代とは隔世の感ある。
論理削除 - kawasima
昔から思うんだけど、フラグ操作で削除したように見せることを「論理削除」と言うことに違和感。レイヤーを下げれば DB のレコード削除も実装によっては同様だし、ファイル削除もそう。物理削除は全然物理じゃない。
> id:JULY physical delete は永続的に操作対象・参照対象でなくなる。という意味ですがどこか問題ありますか？/ 話がややくしくなりそうなとき、特にFKを貼りたいときはクラステーブル継承にして親に貼るのが一番楽だと思う。
ほとんどのケースは削除時に適切なログを残しておくことでカバー出来ると思ってる。そうでないユースケースがあるときだけ真剣に考えれば良い。
これは部分インデックスで出来る気が（PostgreSQL） / "「アクティブユーザで一意であること」のような制約があるとき、削除レコードも含むため、RDBMSのUNIQUE制約を付与できない"
https://www.sesarju.eu/sites/default/files/webform/annual_conf_2022_contrib/_sid_/talk-directly-to-robinhood.pdf
レイヤードアキテクチャの場合外から見える振る舞いと内部実装を一致させる必要がないのがメリットなのでブコメは何を当たり前のことを言ってるんだ感あるんだけど
いつも思うんだけど、個人情報保護法の観点で見るとユーザ情報の削除ってすげぇむずい。大手サービスで問い合わせしてもまともな回答が返ってこないから多分どこも困ってると思うんだけど...
外部キー制約で削除できないとか、無くても不整合にしたくないときは論理削除ではなく、ログイン不可とか意味のある列にすればいい。unique制約のあるメールアドレスとかは重複しないように更新してたな。
？と思ったが、「テーブル継承」←今どきのRDBMSは（またはPostgreSQLは(?)）テーブルの定義を継承できるのか。知らない世界だったというか、それが“新しい世界”なのかな。SQL Serverには見当たらないけど。
簡潔な設計とクエリにしたい場合が多い／メールアドレスのように「アクティブユーザで一意であること」のような制約 > deleted_atなどの削除フラグとメールアドレスをを組み合わせた複合ユニーク制約を定義すればできる
ビジネスロジックとしてその機能が重要なのであればモデリングするし、そうでないなら永続化層で吸収するだけ。
こないだAIに論理削除ロジック書かせたらsoft_deleteって関数名だった。英語ではそう言うのかな。
基幹系とかだとホント消さない。会計なら赤黒で±0にするし給与なら翌月精算だし。削除フラグよりも履歴（開始日終了日）管理で終了日セットのことが多い。
英語だと物理削除: hard delete、論理削除: soft deleteだからそんな違和感ないんよな、「非可逆削除」「可逆削除」とかの方がいいんじゃね？
条件付きのUNIQUE制約を使えるDBなら付与できる→"「アクティブユーザで一意であること」のような制約があるとき、削除レコードも含むため、RDBMSのUNIQUE制約を付与できない"
論理削除の言葉の定義に違和感あるってマジ？手法の善し悪しは別にして復元可能なら論理削除、負荷なら物理削除という区別でいいのでは？
論理削除？データもボクも消さないで欲しいにゃ。寂しいのは嫌にゃ！
個人情報保護の観点で悩む奴。
このやり方はイミュータブルデータモデルを採用する限り、唯一の方法で、他の選択肢は全くない。判断フローも何もない。そしてイミュータブルデータモデルは優れているので採用すべし。論理削除とか悩む必要なし
ドリルで穴をあけるのが物理削除
退会したユーザー「えぇっ、退会したのに私の個人情報残ってるんですか！？」
物理で消す
I
紙とペンでやれば良いのでは…
RDBみたいに最終的にクエリでデータの見え方を決定するような場合に、テーブルを分けるのは繰り返しの排除くらいしかメリットはないと思ってたけど、こうやって意図を明確にする効果もあるのかと思った
id:mohno ここでテーブル継承は概念的でしかなくて、その実現のために全部1テーブルでタイプ列を持つか、複数テーブルに分けるか、idと共通要素抜き出して参照するかを書いてると思います
論理削除:その人を存在しない人間として扱う。物理削除:その人の存在を消す。 物騒だな。
追記オンリーかつイミュータブルであることが目的化してる？。将来的に何も消さなくて済む時代か…HDDが20MBしかなかった時代とは隔世の感ある。