If the deleted row is normalized to a large degree, this doesn’t seem to store that much useful information. The joined data would be interesting to include in the same row, but could of course be too large.
If you delete a user within this implementation, you would probably need to delete all FK’d forum posts (this code doesn’t solve that, right?). And the FK would need to be laxed into being nullable.
Edit: maybe my assumptions are off, and regular cascade delete for FKs are supported. In that case, yay!
Keeping the object_id separate and indexable sounds smart.
If you read both articles closely I think you’ll find that a large part of the motivation is to enable FK cascade deletes to work again – which the usual deleted_at soft-deletion pattern breaks, because it requires you to keep the row, so there is never a deletion which could cascade.
If the deleted row is normalized to a large degree, this doesn’t seem to store that much useful information. The joined data would be interesting to include in the same row, but could of course be too large.
If you delete a user within this implementation, you would probably need to delete all FK’d forum posts (this code doesn’t solve that, right?). And the FK would need to be laxed into being nullable.
Edit: maybe my assumptions are off, and regular cascade delete for FKs are supported. In that case, yay!
Keeping the object_id separate and indexable sounds smart.
If you read both articles closely I think you’ll find that a large part of the motivation is to enable FK cascade deletes to work again – which the usual
deleted_atsoft-deletion pattern breaks, because it requires you to keep the row, so there is never a deletion which could cascade.