User roles schema design comparison

Question

I'm learning how to design a DB structure for assigning users permission to access certain pages

• if the user is an admin that user would have access to crud operations
• if the user is an editor that user would have access to only edit
• user can have custom permission then access it would vary depending on the config

I have two schema designs and both seems good, one requires simple queries and the other can hold more description about each role and permission.

Design 1

role id is stored in a table called user and i will need to lookup role_has_permission table get all the permission ids then lookup permission table to get the permission_name column. comparatively longer query with more data being fetched, but i can have description column in permission table

Design 2

role id stored in table user, i can simply make a single query and check for permission. eg: role.canEdit is set to true user is allowed to edit. smaller and faster query.

why cant i go with the second design? and why do many articles go with the first design?

Answer 1

Design 1 lets you add permissions dynamically without changing the software. If you need a new permission, say can order lunch for entire team , you just add a record in the permission table and as many in the role_has_permission as needed, and you're done. In design 2 you'd have to add an operation canOrderLunchForEntireTeam . So design 1 is more flexible.

However, the flexibility of design 1 has a price. It's not enough to define and assign these permissions, but the software shall probably also check them when a function is performed. Adding a function for ordering lunch is a software change anyway, so adding an attribute to your design 2 class might be tolerable. The generic way of defining permissions in design 1 will therefore only pay out if you implement a similarly generic way of applying them.