Разрешить пользователям удалять свою учетную запись

Question

Я занимаюсь разработкой галереи, которая позволяет пользователям публиковать фотографии, комментарии, голосовать и выполнять множество других задач.

Теперь я считаю правильным разрешить пользователям отписываться и удалять все свои данные, если они этого хотят. Однако это трудно допустить, потому что вы рискуете сломать свое приложение (например, что мне делать, если на комментарий много ответов? Что делать со страницами, которые имеют разные ревизии от разных пользователей?).

Фотографии могут быть легко удалены, но для других данных (то есть комментариев, ревизий ...) я думал, что есть три возможности:

• назначьте его администратору
• назначить его пользователю с именем "Удаленный пользователь"
• поддерживает текущие ассоциации (т. Е. Идентификатор пользователя) и переименовывает только данные пользователя (например, назначает новое имя пользователя, такое как «удаленный пользователь-24» и несуществующее электронное письмо, такое как «noreply-удаленный пользователь 24@mysite.com "

Какую рекомендацию следует соблюдать, когда мы разрешаем пользователям удалять свои учетные записи? Как вы их реализуете (особенно в Rails)?

Answer 1

Обычно я решал этот тип проблемы, имея активный флаг для пользователя и просто устанавливая активный в значение false, когда пользователь удаляется. Таким образом, я поддерживаю ссылочную целостность во всей системе, даже если пользователь «удален». На бизнес-уровне я всегда проверяю, активен ли пользователь, прежде чем разрешить ему выполнять операции. Я также фильтрую неактивных пользователей при получении данных.

Answer 2

Обычно вместо удаления их из базы данных добавьте поле логического флага, чтобы оно было истинным для действительных пользователей и ложным для недопустимых пользователей. Вам нужно будет добавить код для фильтрации на флаге. Вы также должны удалить все соответствующие данные от пользователя, который вы можете. Основная цель этого флага - сохранить ссылки в целости и сохранности. Это вариант переименования данных пользователя, но флаг будет легче проверить.

Answer 3

Я бы рекомендовал ввести поле даты удаления, которое содержит дату / время, когда пользователь отменил подписку - не только для записи пользователя, но и для всей информации, связанной с этим пользователем. Приложение должно проверить поле до отображения чего-либо. Затем вы можете выполнить полное удаление всех записей через 30 дней (по вашему выбору времени) после даты удаления. Это позволит не отображать информацию (вам, вероятно, потребуется обновить приложение в нескольких местах), время, чтобы пользователь мог повторно подписаться (случайное или переосмысление), и запланированный процесс удаления старых данных. Я удалил бы ВСЕ сведения об участнике и любые связанные с ним комментарии об этом участнике или опубликованные ранее данные (фотографии и т. Д.)

Answer 4

В идеале в системе вы не хотели бы «жестко удалять» данные. Лучший способ, который я знаю и который мы реализовали в прошлом, - это «мягкое удаление». Поддерживайте столбец состояния во всех ваших таблицах данных, который в идеале относится к факту, является ли строка активной или нет. Любая строка при создании является «Активной» по умолчанию; однако, поскольку записи удалены; они сделаны неактивными.

Все выбранные запросы, которые отображают данные в результатах фильтра экрана только для «активных записей». Таким образом, вы получаете следующие преимущества: 1. Восстановление данных возможно. 2. У вас может быть запланированная задача на уровне базы данных, которая может позаботиться о жестком удалении одного раза; если действительно нужно. (Как процедура SQL или что-то) 3. Вы можете иметь экран администратора, чтобы иметь возможность решать, какие учетные записи, записи и т. Д. Вы действительно хотите пометить для удаления 4. Временное отключение учетной записи также может быть реализовано тем же решением.

В продуктивных средах, где я работал, жесткое удаление - это строго No-No. Аудит Infact ведется для удаления также. Но если приложение действительно маленькое; это было бы до пользователя.

Я бы по-прежнему предлагал "виртуальное удаление" или "мягкое удаление" с периодической очисткой на уровне БД; который будет более эффективным и оптимизированным способом очистки.

Answer 5

Как правило, я не люблю ничего удалять и вместо этого предпочитаю помечать записи как удаленные / неопубликованные с использованием состояний (с AASM, т.е. действует как конечный автомат).

Я предпочитаю состояния и события, а не просто использование флагов, так как вы можете использовать события для обновления атрибутов, отправки электронных писем и т. Д. Одним махом. Затем проверьте состояния, чтобы решить, что делать дальше.

НТН.