5 Matching Annotations
  1. Mar 2024
    1. Udi Dahan wrote about this in Don't Delete - Just Don't. There is always some sort of task, transaction, activity, or (my preferred term) event which actually represents the "delete". It's OK if you subsequently want to denormalize into a "current state" table for performance, but do that after you've nailed down the transactional model, not before. In this case you have "users". Users are essentially customers. Customers have a business relationship with you. That relationship does not simply vanish into thin air because they canceled their account. What's really happening is:
    2. The truth is that both of these approaches are wrong. Deleting is wrong. If you're actually asking this question then it means you're modelling the current state instead of the transactions. This is a bad, bad practice in database-land.
    3. In any system even remotely tied to money, hard-deletion violates all sorts of accounting expectations, even if moved to an archive/tombstone table. The correct way to handle this is a retroactive event.
  2. Oct 2020
    1. (Roose, who has since deleted his tweet as part of a routine purge of tweets older than 30 days, told me it was intended simply as an observation, not a full analysis of the trends.)

      Another example of someone regularly deleting their tweets at regular intervals. I've seem a few examples of this in academia.