2025-07-28

https://x.com/a_suenami/status/1949457751903777148

idだけは残っておかないと購入履歴などのトランザクション系テーブルの外部キーが死ぬじゃん（CASCADE設定なんてあろうものなら道連れで消えてしまう）という話と、退会するって言ってんだから個人情報消せよって話は両方あるので、id（と必要なら分析用のデモグラ情報）だけ残して他は消すっていうのが出発地点だと思いますね。あとは残したいものは追加で残せばいい

https://x.com/a_suenami/status/1949621333605986675

この件、図にしてみました。僕が設計するときはこれがスタート地点です。ここから「これは残したい」「これは消さないとまずい」みたいな話をし始めます。

https://x.com/a_suenami/status/1949622416474554855

オンラインでアクセスできる場所からは消えて欲しいけど、税務や監査の関係でアーカイブはしておく必要があるみたいなケースもありますよね。そういうときは別のDBにしたり、いっそS3にJSONで置いといたりする。

けっこう目から鱗だった。勤め先は論理削除で無限にDBを膨らませているので（toBなので仕方ないところはある）ちょっとキモかったのだ

• ユーザーが退会処理をしたときにはユーザー情報を物理削除したい
• 後から（それこそ監査とかに必要な時に）参照できないのは困る
• ユーザーが退会した時にユーザーの購入履歴とかまで消えるのは困る（月末集計とか）

みたいなところに対してしっくり来る。
一旦論理削除(is_archiveフラグ)みたいなことをやって、誤削除対策にいくらかの猶予を設け、必要ならjsonでS3にぶん投げるなどして、DBからは個人情報のみ物理削除する。

is_archiveで言うと、古いデータもis_archiveフラグを立てて猶予期間ののちjsonに丸めてS3に投げてDBからは物理削除みたいなことを考えていたのでこれもやりたいな。期間指定になるから個人開発でテストするの結構ダルいんだけど。

しかしかつては「一対一リレーションって何のためにテーブル分けてるの」と思っていたが最近になって腑に落ちるケースがぽろぽろ出てきて面白いな。
仕事でクソデカ設定テーブル（すべての設定が書き込まれる）を見かけたときに「ﾊﾊｰﾝたしかにこれはテーブル分けた方が可視性が上がるわね」と思ってたんだけど、個別にテーブル削除しないならやっぱ傍流なのかな。