у пользователей с ролями работник агентства, индивидуальный работник есть дополнительные поля, которые не свойственны простому потребителю
плюс они связаны с агентством
Я могу сказать на собственном опыте - у нас приложение с ролями разделенными на STI модели. На старте все было ок но потом данные и поведение ролей начало различаться и чем дальше тем больше. И STI теперь больше мешает чем помогает.
А пошли этим путем из-за авторизации - что бы проще было увязать с devise gem.
Те если подытожить - соглашусь с
Viacheslav - если данные разнятся (а они будут, в этом то и причина разделений ролей) то нет особого смысла в наследовании и использовании общей таблицы.
Если бы я писал сейчас с нуля - я бы взял модель User с полями для аутентификации в devise и enum role. И релейшн к профайл который будет отдельной моделью для каждой роли как предлагал
@davydovanton (кстати глянь статью которую он скинул - там боль и причина перехода от STI, оч реалистично - все как у меня). Для себя я вывел правило - очень осторожно относится к STI