We have an existing application that runs on php and mysql. We are in the process of adding fine grained user authorization, so that certain users only get access to certain resources. There are a few thousand users and approx 100 resources (although both are expected to grow).
My DB design is something like:
users:
id, name, email
resources:
id, resource
OPTION 1
So, if we approached this with typical db normalisation in mind, we would have the following table as well. I guess that we would follow the structure of users being denied permission unless there is a record in the user_resources table. If their permission is subsequently removed for a particular resource, then we just delete that row from the user_resources table.
*user_resources:*
user_id, resources_id
OPTION 2
Another alternative would be to forget about the user_resources table and just create a new column in the users table (called permissions or similar) and store a serialized value of that users permissions in the users table. Each time we need to check a user’s permission, we would have to unserialize this value.
Which approach is considered better practice, and are there any major pro’s or con’s to either?
Option 1 is the way to go unless you have solid arguments against it. Adding a column to the users table is fine for role based permissions. You can mix the two options, if you base your permissions on roles but allow to assign different permissions – then write in the table only the exceptions.