Как реализовать такую архитектуру на Eloquent laravel?
Недавно я задавал похожий вопрос, но общего характера и больше про RBAC. С тем вопросом относительно разобрался, но другой остался, его и задаю.
Напоминаю вводную.
Есть проект, в нем такие роли - админ, врач, клиент. У клиента своя анкета, у врача своя. Главный вопрос - если мы врачей и клиентов храним в одной таблице, как лучше хранить их анкеты?
Ведь у врача есть обязательное поле - специализация, например. У клиента его нет, зато есть свое специальное поле, к примеру, это хронические болезни.
Какие варианты вижу я:
1. Все затолкать в одну таблицу (users), нужное подтягивать в зависимости от ситуации. Минус в том, что это бардак в чистом виде - одна таблица двоих еще вместит, а что если там 3-4-5 ролей? Там уже будет хлам.
2. Сделать поле анкета json-ом. Тут тебе и компактность, и нет смешения, но json достаточно недавно в sql для меня, не знаю точно, где его юзать. Да и поиск становится чуть замороченнее.
3. Просто сделать users как базовая модель, а от нее наследовать другие модели - clients и doctors. Тут надо разобраться - как такое сделать и как решать вопрос с авторизацией и как внутри связи устроены? Если этот вариант годный, буду его копать.
4. Увести профили в отдельные таблицы, например, client_profiles и doctor_profiles. Но как тогда корректно прокинуть связь так, чтобы у докторов не было client_profiles (пусть и null'евого), а у клиентов doctor_profiles?..
5. Вышеописанное еще можно сделать так - сделать таблицу profile_attributes, и построчно выставлять соответствие между атрибутом профайла и значением для каждого конкретного юзера - клиента или доктора, не важно.
Короче, понимаю, что варианты есть разные, есть мною не описанные, но хотелось бы понять, какие в этом вопросе best practics?
1. null'и ненужные поля, они не занимают много места. Будет хлам в таблице, но если в коде разбить одну таблицу на несколько моделек - будет уже лучше и спокойней.
2. json - не очень вариант, только если как-то это абстрагируешь и будешь все из json'а пихать назад в аттрибуты, что бы с этим было удобно работать в коде. Но это тоже так себе вариант.
3. если использовать uuid и морф связи без foreign ключей - да, как вариант
4. не создавать профили кому не нужно и все)
5. нет, хрень. Даже хуже чем второй вариант.
В этом конкретном случае я бы выбирал между вариантами 1 и 3, ибо привязывать примитивку "специализация" к какому-то отдельному энтити - такое себе удовольствие. 1-ый не такой плохой как кажется, а с третим теоретически сложнее работать, хотя это неплохая идея.