Re: Design Database, 3 degrees of Users.

Поиск
Список
Период
Сортировка
Искать
От
Merlin Moncure
Тема
Re: Design Database, 3 degrees of Users.
Дата
Msg-id
b42b73150907311207wf980875le51b0123e803fd1b@mail.gmail.com
Ответ на
Список
Дерево обсуждения
Design Database, 3 degrees of Users. Andre Lopes <lopes80andre@gmail.com>
Re: Design Database, 3 degrees of Users. Sam Mason <sam@samason.me.uk>
Re: Design Database, 3 degrees of Users. bricklen <bricklen@gmail.com>
Re: Design Database, 3 degrees of Users. Rich Shepard <rshepard@appl-ecosys.com>
Re: Design Database, 3 degrees of Users. Merlin Moncure <mmoncure@gmail.com>
Re: Design Database, 3 degrees of Users. Steve Crawford <scrawford@pinpointresearch.com>
On Fri, Jul 31, 2009 at 9:47 AM, Rich Shepard wrote:
> On Fri, Jul 31, 2009 at 4:38 AM, Andre Lopes wrote:
>
>> I need to design a Database that will handle 3 degrees of users:
>>
>> Administrators - They can see all the information in the database.
>> Managers - They only can see the information of his dependants.
>> Dependants - Theirs action must be aprovet by the managers.
>>
>> Wich the best way to implement this in PostGreSQL? There is some database
>> examples doing this? Some OpenSource Project?
>>
>> I'am designing a Database for doing this, but I don't have sure I'am doing
>> well.
>>
>> Please give me some advice.
>
>  You don't want to implement this in SQL, regardless of what DBMS you use
> as the back end. Implementing different user classes (or roles as we call
> them) is done in your middleware and UI.
>

That's a fairly broad statement which I don't necessarily agree with
depending on how you define 'in SQL'.  It's quite easy and common to
describe user roles and allowed activities within the database to
support an application, and to check user actions against those tables
at various places.  This is 'in SQL' to me, because the logic
controlling what the users can and cannot do is handled inside the
database (either in tables + actual sql or a supporting language
hooked in to the database).

Strictly using SQL roles for security. however, can be clumsy if you
need fine grained control beyond reading or writing to a particular
set of tables.  This is more of a data security thing, which is quite
different from controlling how a particular application is supposed to
behave.

merlin
В списке pgsql-general по дате отправления
От: John R Pierce
Дата:
От: Adrian Klaver
Дата:
FAQ