views:

56

answers:

2
+2  Q: 

Roles vs Schema

I want to give different level of access on tables to different users based on their department. Should I use Schema or Roles for this purpose. Any Insights!

+6  A: 

Roles would be the way to go here. Roles should be used anytime you have groups (i.e. depts. in your case) that need specific user rights to tables regardless of what schema they are in. This prevents errors, and makes the job of the DB administrator much easier.

Think of roles as groupings for users and the associated rights for that group of users, while schemas are for the logical grouping of sets of data.

Edit based on user comment:

You can, but to limit access to a particular table using schema is maybe not the best way to think about it. Schemas are used for grouping of data. So you may have a "sales" schema that has tables, procedures, etc. that are needed by the sales team. You can then say GRANT SELECT ON SCHEMA::sales TO salesRole; where you are using a schema as a shortcut to granting permissions to a group of users where each sales person granted the salesRole role. Any table that is later created in the sales schema will be selectable by the users with that role as well. If the sales team only uses this role and has no other permissions, then a table created in another schema will not be useable by those users. If that is what you mean by "restricting access using schema", then yes, but I prefer to look at it as the user not having rights granted either through a role or an explicit grant. Hope that this helps to clarify.

RC
Got your point, Thanks. Can I restrict some user from accessing any particular table only by using Schema.
vaibhav
A: 

You can use a combination of both. Uses schema to separate objects that logically can be group together. Uses roles to create different access configuration and grant access on the schemas to the roles you have already created (according to your business logic).

Dani Cricco