Как правильно организовать хранение пользователей в базе данных?

Question

[Артём Белобородов]

Есть три типа пользователей:
- посетители
- спикеры
- участники выставки

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

В дальнейшем планируется приложение в котором все три категории смогут общаться друг с другом. Т.е. единая точка входа.

Проблема-Вопрос:
Сейчас все три категории пользователей хранятся в разных таблицах и по сути это разные модели.
В целом все понятно кроме этапа соединения всех трех сущностей для организации единой точки входа в приложение. Как устранять потенциальные дубли и делать выборку по трем таблицам.

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

Как бы вы спроектировали хранение трех разнородных сущностей, требующих единого идентификатора для авторизации?

Comments

[JhaoDa]

Сначала ты пишешь, что «всё понятно», подразумевая хранение, но потом всё равно спрашиваешь «Как бы вы спроектировали хранение». Определись.

Аутентификация (не авторизация!) хоть по сотне таблиц без проблем делается через кастомные guard/user provider.

[Роман Сохарев]

rtfm
https://laravel.com/docs/5.8/eloquent-relationship...

Answer 1

[Алексей Уколов]

Для этого есть готовый механизм: Custom Guards.

трех разнородных сущностей, требующих единого идентификатора для авторизации?

Если вам действительно нужен единый сквозной идентификатор, то проще всего использовать одну таблицу регистраций + N таблиц профилей (по одной для каждого типа).

Как устранять потенциальные дубли и делать выборку по трем таблицам.

Это сильно зависит от логики и требований приложения.