Как правильно организовать хранение пользователей в базе данных?
Есть три типа пользователей:
- посетители
- спикеры
- участники выставки
У каждого типа свой набор полей и логика.
- Посетители регистрируются, отмечают интересующие мероприятия, по сути все. Регистрируются сами, если что могут восстановить пароль.
- Спикеры участвуют в мероприятиях, по большей части они добавляются не сами, а своими агентами. Могут иногда возникать дубли, которые фиксятся.
- Участники выставки также добавляются своими агентами, по сути просто как представители-публичные лица.
В дальнейшем планируется приложение в котором все три категории смогут общаться друг с другом. Т.е. единая точка входа.
Проблема-Вопрос:
Сейчас все три категории пользователей хранятся в разных таблицах и по сути это разные модели.
В целом все понятно кроме этапа соединения всех трех сущностей для организации единой точки входа в приложение. Как устранять потенциальные дубли и делать выборку по трем таблицам.
Если все типы пользователей объединять и хранить в одной таблице с доп полями, то возникает вопрос логического разделения бизнес процессов и сложности при добавлении новых пользователей агентами, если такие уже есть.
Как бы вы спроектировали хранение трех разнородных сущностей, требующих единого идентификатора для авторизации?
трех разнородных сущностей, требующих единого идентификатора для авторизации?
Если вам действительно нужен единый сквозной идентификатор, то проще всего использовать одну таблицу регистраций + N таблиц профилей (по одной для каждого типа).
Как устранять потенциальные дубли и делать выборку по трем таблицам.
Это сильно зависит от логики и требований приложения.
Простой
