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

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

HTH.

Answer 4

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

Answer 5

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