MYSQL database design to Serialize or not

Question

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?

Answer 1

Option 2 is creating a database inside a database. That might not be what you want to do. And you can run into problems that you might not expect at first .

Both options have pros and cons, it is the question for what you actually want to use your database(s). Normally option 2 is considered to be bad practice because it degrades the use of the database and makes data stored less accessible.

See as well Serialized data in mysql database needs to combined in an array .

Answer 2

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.

Answer 3

In this case its better to use option 1 because:

• Using option 2, you are denormalizing the data. Its difficult to write a query on this data. Any time you want to use it you have to first unserialize it.

• Serialization and storing is a good option when the data is large and published, as in you won't change it in future and may require for audit purpose only. For eg: an order with serialized product details.

• Your data and related elements are too small to even consider the option 2

Answer 4

I would go for option2 for logged-in user auths, but you must check your needs as the guys said it's a matter or design if your site or app query it once and register it in some kind of [userdata]object why not use option2.