Geoff,

> >> However Claudio did say:
> >> > It's possible to create more complex schemas by granting
> >> > roles to roles (and it's in the standard), but we don't
> >> > support that capability.
> >>
> >> This aspect has been mentioned before and I believe it is very
> >> important. If we had this ability then suddenly the whole
> >> issue of privilege management becomes much easier.
>
> > I agree, that can help.
>
> > However, without allowing for a user to have multiple roles
> > active-simultaneously, the number of roles which must be
> > defined to cover all possible combinations works out to be
> > n^2-1.
>
> This is really no different to groups, it is just that the
> accumulation point is different.

I don't agree.

In my model I only have to define n roles and then link the users to the
roles (multiple) as appropriate.


Role A
Role B
Role C
Role D

User A -> Role A
User B -> Role B
User C -> Roles A & B & C
User D -> Roles A & B & C & D

> In NT domains each user can get multiple group associations,
> giving very good flexibility at the user level. But this in
> itself can get quite confusing, suddenly you have to study
> each user in detail to understand what privileges have been
> given out.

Actually, you can look at the security from the group level as well, but
that is a side point.

The analysis of FB privileges can be just as confusing, today, given
that the user can choose a role themselves on sign-in.

> To get the desired effect with SQL roles it is just a matter
> of adjusting your technique a little.
>
> A theoretical example would be:

I don't see how your example accomplishes the goal, or certainly in a
manner which is as straight-forward as the one I outline above.


Sean