No a user is a user
An individual may have one or more role in the db. for example a user may have clearance to look at data, but not change it,
a user may have rights to change normal data, but view masterfile data.
a system administrator may have rights to view data but not change it.
a system operator may have rights to run reports nut not data viewing or modification
but those are roles, you may have multiple system operators.
a person may move roles within the organisation, for example (someone with masterfiels cleaerance will probably also have normal data clearance.
By assigning security policies to roles, and users to roles you have a way of allowing a specific user to have the permissions they need to do their work, you have the granularity to allocate permissions as required, and the flexibility without a significant maintenance task
someone may move from accounts receivable to accounts payable, and you may decide to switch the roles that person is entitled to use. so if you had a user role / group for each tack moving the user is simple. if you allocate permissions at user level then you have to have a lot more knowledge about the application(s) that user used to use, and now is expected to use. One of the practical problems in implementing security is often remembering to remove permissions form users as they move through an organisaiton.
I'd rather be riding on the Tiger 800 or the Norton