Ерунда денормализованная.

Есть пользователи. Есть роли. Есть отношение пользователь-роль. То, что "у клиента есть оператор", говорит лишь о том, что у роли "клиент" есть компонент "оператор", вследствие чего у экземпляра "пользователь", имеющего значение атрибута "роль", равного "клиент", будет атрибут "идентификатор оператора".

Реализовывать подобную схему (шаблон роли -> атрибуты экземпляра пользователя) удобнее всего как EAV.

Кирилл ГолодаеаRBAC реализован.Это понятно.

Кирилл ГолодаеаEAV не подойдетПричина?

Кирилл ГолодаеаМне не нравиться данный подходКакой именно? EAV?

Кирилл ГолодаеаНужно отдельная таблица для клиентовИз физики бизнес-процесса это никак не проистекает. Но хотите так - делайте так... только тогда настоятельно советую сделать клиента отдельной сущностью (и опера, и админа - ещё 2 отдельных), а с сущностью "человек" попрощаться.

Кирилл ГолодаеаДелают так: заводят таблицу профиля "forum_user" и добавляют нужные поля для форума.Не всегда. Во всяком случае не так категорично.

Вариант первый - разреженная таблица. Общая таблица пользователей со всеми полями, для любой роли, в полях для отсутствующей роли Null. Не худший вариант, но сложно писАть констрейнты на целостность.

Вариант второй - EAV. По сути совершенно то же самое, да и проблемы те же, только место экономится.

Вариант третий - базовая таблица общих атрибутов и частные таблицы атрибутов для каждой роли. Имхо наиболее употребительный вариант. Сбалансированный. И в Вашем случае тоже (хотя и не так удобен, как EAV). И ещё я бы его дополнил слоем хранимых процедур, полностью отделив юзера от данных и вынеся логику на сервер. Это заодно позволит сделать роль не сущностью, а атрибутом, отдав всю шаблонизацию и контроль процедурам. Ну и упростит работу конечного пользователя - ценой усложнения разработки, но она-то как раз одноразовая.

Дело Ваше, думайте.