Soft delete на собеседовании системного аналитика

Идея soft delete

Не DELETE row. Mark as deleted с flag / timestamp.

Зачем:

• Audit trail (кто, когда удалил).
• Restore (oops, не хотел).
• Reporting (включая deleted данные).
• Foreign key integrity (orders на deleted users).

Implementation

ALTER TABLE users ADD COLUMN deleted_at TIMESTAMP;

-- soft delete
UPDATE users SET deleted_at = NOW() WHERE id = 42;

-- queries
SELECT * FROM users WHERE deleted_at IS NULL;

В ORM — global filter:

class User(Model):
    deleted_at = Column(DateTime)
    
    @classmethod
    def query(cls):
        return Session.query(cls).filter(cls.deleted_at.is_(None))

Restore

UPDATE users SET deleted_at = NULL WHERE id = 42;

Часто с time window — если > 30 days, no restore.

UI — «Recently deleted» folder (Gmail / Dropbox).

Cascading

User soft-deleted → что с orders?

Options:

• Cascade soft delete. Orders тоже marked deleted.
• Set to anonymous. Orders.user_id = anonymous_user_id.
• Keep references. Orders точно ссылаются — display anonymous label в UI.

Compliance — GDPR right to be forgotten — иногда требует hard delete.

Index considerations

Most queries WHERE deleted_at IS NULL. Add это в indexes.

CREATE INDEX idx_users_active_email ON users(email) WHERE deleted_at IS NULL;

Partial index — только active rows. Faster и smaller.

GDPR / compliance

Soft delete не satisfies «right to be forgotten» — data still там.

Hybrid approach:

• Soft delete для recovery period (30 days).
• After period — hard delete.
• Или anonymize: replace PII с null / placeholder.

Audit log retention — отдельно регулируется.

Связанные темы

• Database migration для SA
• 152-ФЗ для SA
• GDPR vs 152-ФЗ для SA
• Logging strategy для SA
• Подготовка к собесу системного аналитика

FAQ

Это официальная информация?

Нет. Статья основана на индустриальных database practices.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.