Разработка схемы базы данных: что делать с непроверенными приглашениями?

Question

Я не совсем уверен, как подойти к этому вопросу:

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Кроме того, приглашение является отдельным объектом от регистрации. Я думаю, что вы должны создать отдельную таблицу для отслеживания приглашений против, чтобы увидеть, кто зарегистрировался (из какого приглашения)

Answer 3

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

Answer 4

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

Answer 5

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