Всем привет. Есть задача дать возможность пользователям авторизовываться с разных таблиц. Допустим, у меня есть стандартная таблица users, где хранятся простые пользователи. Есть ещё таблица, где хранятся аккаунты предприятия (почти те же пользователи, но с другими данными). Вот думаю, как лучше поступить с авторизацией:
1. Сделать общую таблицу и просто заполнять только определённые данные (простой пользователь или компании)
2. Сделать разные таблицы и как то в контроллере делать авторизацию для компаний.
По сути функционал почти не меняется, так что думаю сделать в одной таблице users и не париться, прикрутив Permission. Но скорей всего при первом варианте будут подводные камни в дальнейшем, т.к. функционал в планах различный - что-то типо групп ВК. Компании могут создавать группу, где пользователи могут контролировать все действия. Так что придётся добавлять "внутренних администраторов", "модераторов" и т.п.
Я когда делал что-то подобное то у меня была одна таблица users где хранились общие данные для разных групп, и для каждой группы была своя таблица где хранились уникальные для нее данные. Не уверен что это хорошее решение, но это работало
Есть два варианта:
1. Общая таблица всех пользователей и права, и возможности разруливаются другими таблицами с правилами. Подойдет для "Раз и забыл"
2. Если возможны кардинальные изменения и могут появится другие авторизации, требования, возможности. То тогда лучше выделить пользователей в разные таблицы и создать разные классы с нужными методами.
Сейчас подумал. поразмышлял. Твой подход и мое предложение разбить на разные таблицы нарушает принципы SOLID, а именно "Открытость/Закрытости" и "Подстановки Барбары Лисков".
Суть в том, что нижние интерфейсы не должны менять внутреннюю структуру старших интерфейсов.
Просто добавь поле в таблице пользователей group_id и записывай там айдишник группы. Группы будут хранится в отдельной бд.
Разрешения будут привязываться к группе. А группы это и есть твои роли, типы пользователей.
Таким образом ты получишь много гибкости наряду с универсальностью, как например, повышение/понижение прав/роли, перевод пользователя в другой статус, контроль безопасности, разделение для рассылок, ...
Простой
Простой
