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

Question

Контекст

Я разрабатываю базу данных (Postgres), которая должна иметь возможность управлять Учащимися и Инструкторами , с оговорками, которые Пользователь может одновременно быть и Учеником и Инструктором , и что учетные записи студентов или преподавателей могут находиться в состоянии ожидания, пока они не завершат входящий поток. , Мне нужен мой интерфейс, чтобы можно было легко определить, является ли пользователь студентом или инструктором, и нужно ли ему заканчивать 1053 * аттестацию.

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

Попытка решения

До сих пор я думал о том, чтобы иметь таблицу Users, содержащую базу информация, совместно используемая как Students и Instructors, а затем использовать наследование таблиц классов, имея таблицу Students и таблицу Instructors с FK обратно в таблицу Users.

Для обработки ожидающих Учетные записи, я думал, что мог бы иметь таблицу PendingStudents и таблицу PendingInstructors с FK обратно к таблице Users и свойством completed_onboarding_step, которое представляет, где они находятся в потоке. Однако это означало бы две таблицы с одинаковыми свойствами, что звучит неправильно.

Наконец, для управления сохраняющимися данными во время регистрации у меня будет таблица TemporaryStudentData и таблица TemporaryInstructorData для удерживайте необходимые свойства, которые будут NULLABLE, и верните FK обратно в таблицу PendingInstructors/Students. Тогда у меня может быть cron-задание, которое удалит эти записи через столько дней.

Вопросы

1. При такой настройке я не сохраняю никаких данных на Users таблица о том, является ли пользователь Student, Instructor или обоими, или находится ли он в состоянии ожидания или завершен. Это означает, что для того, чтобы мой интерфейс мог узнать, каков статус пользователя, мой сервер должен был бы выполнить поиск по всей таблице Instructors, таблице Students и таблицам PendingX. Это не звучит правильно или исполнитель. Итак, как лучше всего смоделировать все это так, чтобы мой интерфейс мог легко определить, где именно пользователь находится в потоке и находится ли его учетная запись в состоянии ожидания / завершения, и т. Д. c.

Большое спасибо за вашу помощь / время.

Answer 1

Предлагаю сначала попробовать с легким дизайном. Вам нужно как минимум 2 таблицы:

• Пользователь с указанным c первичным ключом user_id (например, последовательным), завершено_boarding_step, флаги is_pending_student, is_pending_instructor, is_student, is_instructor и, возможно, связанные дата / время, когда статус имеет был изменен
• Instructor_data с указанным первичным ключом c (например, серийным) и внешним ключом, ссылающимся на User.user_id.

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