Архитектура базы данных в отношении учетных записей пользователей и удаления учетных записей

Question

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

Учетные данные пользователя будут состоять из электронной почты и пароля.Столбец электронной почты таблицы будет уникальным, поэтому адрес электронной почты может быть сопоставлен только с одной учетной записью.

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

Итакчто произойдет, если пользователь закрыл свою учетную запись, но попытался создать новую учетную запись с тем же адресом электронной почты?Им не будет разрешено, потому что уже есть учетная запись с этим адресом электронной почты и статусом прекращено.

Моя первая идея состояла в том, чтобы заменить адрес электронной почты на ноль, когда учетная запись прекращается.Таким образом, электронная почта может быть снова использована для новой учетной записи, но затем я понял, что уникальный столбец может иметь только одно значение NULL.

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

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

AccountInventory: AccountID_PK, статус

ActiveAccounts: AccountID_PK, электронная почта, пароль, PasswordSalt, AccType, AccStatus

TerminationAccounts: AccountID_PK, AccType

Таким образом, ямог ссылаться на таблицу AccountInventory с внешними ключами в других моих таблицах.Используйте таблицу ActiveAccounts для проверки учетных данных при входе пользователей. И перемещайте удаленные учетные записи в таблицу TerminationAccounts, сохраняя при этом ссылочную целостность других данных в этой учетной записи, так как внешние ключи ссылаются на AccountInventory.

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

Так что это лучшее решениеили есть более разумный способ сделать это?

С уважением, Дункан

Answer 1

Похоже, вам следует изменить свой взгляд на учетные записи пользователей.

В вашей системе пользователям не разрешено удалять свои учетные записи.Когда вы думаете об этой проблеме, прекратите использовать слово delete ;это затуманивает ваше мышление.

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

Это зависит от вашего приложения, но я не думаю, что что-либо, кроме статуса их аккаунта, должно быть распознано как «активное» или «неактивное».».Другими словами, я не думаю, что исторические сообщения, заказы и споры должны знать что-либо о текущем состоянии аккаунта.

Еще одна важная вещь, о которой стоит подумать

Допустим, у меня есть свой собственный домен - wibble.com - и у меня есть учетная запись электронной почты с именем mary@wibble.com.Я позволил своему домену истечь.Кто-то еще, также по имени Мэри, регистрирует это.Что должно произойти, когда новый mary@wibble.com пытается создать учетную запись на вашем сайте?

Если это звучит неправдоподобно, местный университет назначает адреса электронной почты каждому студенту во время регистрации.Университет закрывает эти счета через 6 месяцев после вашего окончания.Имена пользователей основаны на буквах в вашем настоящем имени.Прекращенные адреса электронной почты можно повторно использовать сразу после прекращения.Тот же адрес электронной почты;другой человек.Что должно произойти?

Answer 2

А как насчет таблицы пользователя с уникальным ключом на основе адреса электронной почты и статуса?

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

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