Мы разрабатываем и используем приложение для ведения блогов, в котором пользовательские данные разбросаны по многим таблицам:
- Блог
- статья
- Комментарий
- Сообщение
- трекбек
- 50 других таблиц.
Пользователи могут закрыть свою учетную запись, и их учетная запись / содержимое должны немедленно исчезнуть с сайта.
По юридическим / договорным причинам мы также должны иметь возможность восстановить их учетную запись / контент на определенный срок, а также предоставить эти данные для юридических лиц на другой срок.
На протяжении многих лет и различных применений мы использовали разные подходы:
флаг «удален» везде: в каждой таблице есть столбец «удален», который обновляется при удалении / восстановлении данных. Очень неприятно, потому что это замедляет все запросы генерации списка, создает много обновлений после удаления / восстановления. Кроме того, он не обрабатывает двухэтапное удаление, описанное выше. На самом деле мы никогда не пользовались этим, но его стоит не советовать :)
«Multi table»: для каждой таблицы мы создаем вторую таблицу с той же схемой плюс два дополнительных поля (dateDeleted, причина). Дополнительные поля используются для того, чтобы узнать, доступны ли данные для восстановления, когда их удалять и почему / как они были удалены в первую очередь. Эта версия немного лучше, чем предыдущая, но может быть очень плохой по производительности, когда таблицы растут. Кроме того, вам нужно изменить схему некоторых таблиц (то есть: удалить ограничения UNIQUE), что затруднит понимание / обновление системы для новых разработчиков, администраторов ... и психически здоровых людей в целом.
«Multi DB»: тот же подход, что и раньше, но мы перемещаем данные в другой кластер базы данных, что позволяет просматривать эти данные, не влияя на базу данных «конечных пользователей». Кроме того, для этого приложения ограничение уникальности выполняется на уровне Java, поэтому все схемы одинаковы. Наконец, ограничение двойного хранения данных достигается выделением БД для каждого ограничения, что облегчает задачу.
Я должен признать, что ни один из этих подходов не удовлетворяет меня, даже если они могут работать с определенным количеством данных. Я также предположил, что мы могли бы просто удалить некоторые ключевые строки в БД, а остальные оставить непоследовательными (и запланировать более контролируемое удаление), но это пугает меня ...
Знаете ли вы другие способы сделать то же самое, сохранив тот же уровень возможностей (мы могли бы согласовать две длительности, чтобы упростить проблему)? Я не ищу решение для своих существующих приложений, но хотел бы улучшить следующие.
Любой вклад будет высоко оценен!