У меня есть внештатное веб-приложение, которое позволяет пользователям регистрироваться на события. В моей базе данных у меня есть таблица t_events_applicants с столбцом t_events_applications.user_id с ограничением внешнего ключа, связанным с столбцом t_users.user_id. Таким образом, это означает, что пользователи, зарегистрировавшиеся в моем веб-приложении, могут зарегистрироваться для событий моего веб-приложения.Таблица временных пользователей или законных пользователей?
Теперь мой клиент должен разрешить незарегистрированным пользователям, не имеющим записи в моей таблице t_user, регистрироваться для событий. Эти незарегистрированные пользователи должны указать свое имя и адрес электронной почты для регистрации событий.
Должен ли я создать таблицу t_temporary_user с именами столбцов и электронной почтой, а затем удалить ограничение t_events_applicants.user_id fk? Или я должен добавить незарегистрированных пользователей в таблицу t_user, а затем добавить столбец t_user.type, где тип может быть «зарегистрирован» или «незарегистрирован»?
Как я могу решить, с каким подходом идти?
Много раз, я смущаюсь ни с подходом. Я спрашиваю себя: «Что, если в более позднее время временному пользователю разрешено стать полностью зарегистрированным пользователем? Тогда, возможно, у меня должна быть только таблица t_user. Но тогда мне также не очень нравится хранить много временных пользователей в t_user. "
Мне очень нравится идея ролей. Я большой поклонник хранения всех данных централизованно, но проблема, которую я вижу при сохранении всех пользователей в одной таблице, заключается в том, что мы теряем ограничения. Было бы слишком много полей с нулевым значением, и программисты должны помнить, что нужно проверить все обязательные поля; включая новые. Я знаю, что всегда должна быть только одна функция, вставляющая строки, но мне нравится добавленная безопасность предотвращения попадания плохих данных в систему. – JohnathanKong
Итак, вы говорите, что в зависимости от того, какие роли у пользователя есть, к этому пользователю нужно добавить больше свойств? В этом случае, возможно, поместите поля, которые принадлежат только определенной роли в таблице «многие ко многим»? Это не решит поля, которые принадлежат более чем одному, но не более одной роли. –