Return to Answer

added 3 characters in body

Source Link

edited Jun 16, 2021 at 7:20

Approach #2 is definitely wrong because it allows for insertion anomalies.
I'd go with approach 1 but with one improvement: if you don't have roles the administration will be a nightmare souso you need roles.
With roles you don't have to assign the same set of permissions again and again to different users.
The problem of giving a user absolute permissions over a given resource is no longer a problem also because you would have already created a "super user" ROLE will all permissions on that object. You simply grant that role to the user.

A more complete model should allow for permissions to be defined separatelly and associated with resources so you don't have to create the same permissions over and over again for different applications/resources with the risk of repeating permissions with different spellings (an anomaly normalization seeks to avoid). So you have a general permission tables and in the RESOURCE_PERMISSION table you define which permissions are suitable for what resources. ROLE would themthen use those.

Approach #2 is definitely wrong because it allows for insertion anomalies.
I'd go with approach 1 but with one improvement: if you don't have roles the administration will be a nightmare sou you need roles.
With roles you don't have to assign the same set of permissions again and again to different users.
The problem of giving a user absolute permissions over a given resource is no longer a problem also because you would have already created a "super user" ROLE will all permissions on that object. You simply grant that role to the user.

A more complete model should allow for permissions to be defined separatelly and associated with resources so you don't have to create the same permissions over and over again for different applications/resources with the risk of repeating permissions with different spellings (an anomaly normalization seeks to avoid). So you have a general permission tables and in the RESOURCE_PERMISSION table you define which permissions are suitable for what resources. ROLE would them those.

Approach #2 is definitely wrong because it allows for insertion anomalies.
I'd go with approach 1 but with one improvement: if you don't have roles the administration will be a nightmare so you need roles.
With roles you don't have to assign the same set of permissions again and again to different users.
The problem of giving a user absolute permissions over a given resource is no longer a problem also because you would have already created a "super user" ROLE will all permissions on that object. You simply grant that role to the user.

A more complete model should allow for permissions to be defined separatelly and associated with resources so you don't have to create the same permissions over and over again for different applications/resources with the risk of repeating permissions with different spellings (an anomaly normalization seeks to avoid). So you have a general permission tables and in the RESOURCE_PERMISSION table you define which permissions are suitable for what resources. ROLE would then use those.

Source Link

answered Aug 29, 2016 at 7:03

Approach #2 is definitely wrong because it allows for insertion anomalies.
I'd go with approach 1 but with one improvement: if you don't have roles the administration will be a nightmare sou you need roles.
With roles you don't have to assign the same set of permissions again and again to different users.
The problem of giving a user absolute permissions over a given resource is no longer a problem also because you would have already created a "super user" ROLE will all permissions on that object. You simply grant that role to the user.

A more complete model should allow for permissions to be defined separatelly and associated with resources so you don't have to create the same permissions over and over again for different applications/resources with the risk of repeating permissions with different spellings (an anomaly normalization seeks to avoid). So you have a general permission tables and in the RESOURCE_PERMISSION table you define which permissions are suitable for what resources. ROLE would them those.