Как вы справляетесь с удалением пользователей

Question

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

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

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

Хотите знать, как другие решают эту проблему?

Answer 1

Обычно мы просто удаляем софт пользователей.Другими словами, имейте столбец в таблице пользователей, указывающий, что они больше не активны, и измените все запросы так, чтобы они работали только с активными пользователями.

Это имеет два преимущества:

• не заполняет ограничения внешнего ключа другими таблицами;и
• он сохраняет все данные на случай, если вам понадобится восстановить их в какой-то момент.

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

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

Если вы пропустили информацию пользователя NULL (или даже если у вас был один пользователь Unknown для назначения сообщений)если бы вы не хотели разрешать значения NULL), у вас не было бы этой информации.

Answer 2

Я бы пошел с подходом, который вы упомянули последним, т.е. с помощью Soft Delete.Установите флажок «Активный» и отметьте его как неактивный после удаления пользователя.

Что касается желания использовать тот же идентификатор пользователя, я бы посоветовал не делать userId вашим первичным ключом.

В этом случае вы можете использовать один и тот же идентификатор пользователя - при условии, что вы проверяете, что другого «активного» пользователя нет - вы не разрешаете старому пользователю повторно активировать свой Id, если тольконе является другим «активным» пользователем

Однако этот подход требует, чтобы внешний ключ для всех других таблиц был столбцом некоторого типа IDENTITY, а не вашим идентификатором пользователя.При условии, что это сделано (и что МОЖЕТ потребовать много изменений схемы, если вы еще не используете ID), я не вижу никаких других потенциальных проблем с этим подходом