Задача: в системе должно быть 2 группы пользователей:
1) "агенты"
2) "администраторы"
 
Агенты занимаются тем, что добавляют ("от своего имени") некие данные в базу и ждут пока эти данные проверят.
Администраторы делают то же самое, но кроме того ещё проверяют данные полученные от агентов (разрешить || не разрешить), т.е. админ - это тот же агент, только с большими правами.
 
Так вот... Как лучше организовать таблицы? У меня 2 варианта:
a) Общая таблица для админов и агентов, а в ней поле - "is_admin" (bool)
b) Таблица агентов и таблица админов (куда записывать ID агентов, имеющих права администратора) связанные 1:1.
 
Кроме того не догоняю как лучше сделать иерархию классов
a) Класс User и дочерние - Admin и Agent
b) Класс Agent и дочерний, Admin (рассширяющий функции родителя)
 
Короче, как лучше?...
 
[offtop]издвините, случайно рано нажал на энтер[/offtop]

a) Общая таблица для админов и агентов, а в ней поле - "is_admin" (bool)
b) Таблица агентов и таблица админов (куда записывать ID агентов, имеющих права администратора) связанные 1:1.

Мне a) больше нравится. Зачем лишняя таблица?
 

Кроме того не догоняю как лучше сделать иерархию классов
a) Класс User и дочерние - Admin и Agent
b) Класс Agent и дочерний, Admin (рассширяющий функции родителя)

А какая функциональность будет у обоих?

и те и другие добавляют-редактируют-удаляют данные. Но агенты работают только со своими данными, а админы - с любыми.

делай поле is_admin binary
и если он пытается чужое редактировать проверй if (is_admin)

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

Я вообще не люблю в подобных случаях создавать объекты-юзеры. Ведь использоваться будет только один из них. Да и он, это скорее соответствует не реальному объекту (пользователю), а учетной записи, а смысл её — привилегии доступа к чему-либо, имеющие для каждого конкретного сценария всеобъемлющий смысл.
Я бы при авторизации запомнил где-нибудь, админ это или не админ, а в каждом методе, выполняющем действия требующие админских прав, проверял эту переменную.

если система не будет развиваться - нормальное решение, но имхо - более универсальное сделать роли
 
потому как возможно, например, такое развитие событий:
еще одна группа агентов, у которых будут подчиненные агенты, с правами - утверждать свои записи и записи подчиненных, или по-раздельно как на форуме..
 
все от задачи зависит

Я бы при авторизации запомнил где-нибудь, админ это или не админ, а в каждом методе, выполняющем действия требующие админских прав, проверял эту переменную.

не понял, а где это запомнить - в глобальной переменной?
 

но имхо - более универсальное сделать роли

блин, мне бы где-нибудь почитать про это или пример какой посмотреть... а то упорно не догоняю... хочеться что бы всё красиво было.....
 

не понял, а где это запомнить - в глобальной переменной?

Да где угодно. В простейшем случае для такой задачи я бы сделал статический класс users, например, который бы отвечал за авторизацию, проверку привилегий и т.п. При авторизации/загрузке сеанса он бы сохранял статус пользователя в скрытом поле, и возвращал бы по запросу:

лин, мне бы где-нибудь почитать про это или пример какой посмотреть... а то упорно не догоняю... хочеться что бы всё красиво было.....

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

А права стандартные или тоже будут создаваться?

так... значит сделал "по ролям"
 
1. таблица member ("члены", блин...)
2. таблица role ("роли" "членов")
3. таблица article (ну типа объекты на которые распрастраняются права, а именно таблица портфолио, таблицы справочников и таблица пользователей member)
4. таблица permission, cвязывающая role и article (М:М). С ней и возникли траблы...
 
проблема в том, что к разным объектам article применяются разные действия:
- информацию в справочниках можно просматривать, добавлять, изменять и удалять;
- портфолио можно добавлять, изменять, удалять, а так же разрешать-блокировать, кроме того члены одной роли (агенты) могут работать только со своими портфолио, а члены другой (одмины) - с любыми;
- пользователей можно добавлять, изменять, удалять, а так же разрешать-блокировать,
- статистика, которую вообще можно только просматривать, ну и очищать, наверное...
 
вот как всю эту фигню запихнуть в одну таблицу permission? сначала сделал так:

role | article | read | readall | append | update | remove | block

но в этом случае, например для справочников поля readall, block получаются "левыми", для статистики вообще не нужно ничего кроме read и remove
 
Может лучше создавать для каждого типа объектов отдельную таблицу? (ну типа permission_handbook, permission_portfolio, permission_member и т.д.) Или я вообще загнался и не то делаю?

а почему не
role - int
article - int
permition - text

Вообщем решение плавало на поверхности :) Разделил объекты, например права на member деляться на права на личную информацию (для редактирования своей учётной записи - для всех участников) и права на работу с учётными записями всех пользователей (одмин онли :).
Оставил role, article, status - где status, число от 0 до 7 (000...111, "read-write-control").
и всё :) Осталось только накодить теперь кучу классов...