Должны ли регистрации на сайте храниться в отдельной таблице для активных пользователей?

Question

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

Преимуществом этого было бы то, что операции чтения из таблицы users не загромождены никогда не активированными регистрациями.Другим преимуществом является то, что поле email (имя пользователя) может оставаться уникальным в таблице users, но если вы попытаетесь зарегистрироваться с помощью адреса электронной почты, который вам не принадлежит, владелец этого адреса электронной почты все равно сможет зарегистрироваться с его помощью, поскольку поле email не будет уникальным в таблице регистраций.

Мне интересно, является ли это обычной практикой или есть какая-то причина, по которой это не очень хорошая идея?

Answer 1

Активирован или нет

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

Электронная почта

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

Но что, если другой парень просто удалит его?

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

или

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

Answer 2

Я думаю, что это было бы излишним инженерством.

Сохраните их все в одной таблице и запланируйте SQL-запрос (каждый день) для удаления неактивированных учетных записей старше 30 дней.

Answer 3

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

Ваше оправдание по поводу адресов электронной почты глупо.Вряд ли кто-то получит блокировку своей электроннойпочты из-за ложной регистрации.

Answer 4

Может быть один случай, в котором вы бы логически разделили две таблицы:Если в процессе вашей регистрации запрашивается много обязательной пользовательской информации, только после того, как вы подтвердите адрес электронной почты.Например, если в вашей таблице ожидающей регистрации будет всего несколько столбцов, таких как e-mail и ключ активации, в то время как в вашей таблице пользователей есть много дополнительных столбцов, таких как имя пользователя, фамилия, почтовый адрес и т.д.

Разделение может иметь смысл в этом случае, поскольку вы сможете объявить эти столбцы NOT NULL.

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

Answer 5

Я согласен с этой практикой по причинам разделения интересов:"Процесс регистрации" и "учетные записи пользователей" - это два отдельных понятия.

Таблица регистрации будет использоваться для сохранения статуса "процесса регистрации".Как только этот процесс будет завершен (как только электронное письмо будет подтверждено), "результатом" процесса станет новая "учетная запись пользователя".Если процесс завершается неудачей (например, "истекает время ожидания" после того, как пользователь не может подтвердить свою электронную почту в течение 1 месяца), это никак не влияет на концепцию "учетной записи пользователя".

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