Role-based access in MySQL - Time & Space Complexity
When checking user permissions based on roles, the time it takes depends on how many roles and permissions exist.
We want to know how the work grows as the number of roles and permissions grows.
Analyze the time complexity of the following code snippet.
SELECT p.permission_name
FROM permissions p
JOIN role_permissions rp ON p.permission_id = rp.permission_id
JOIN user_roles ur ON rp.role_id = ur.role_id
WHERE ur.user_id = ?;
This query finds all permissions for a user by joining user roles to role permissions and then to permissions.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Joining tables to find matching roles and permissions.
- How many times: For each role the user has, the query checks all permissions linked to that role.
As the number of roles a user has and the number of permissions per role grow, the work grows too.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 roles | Checks permissions for 10 roles |
| 100 roles | Checks permissions for 100 roles |
| 1000 roles | Checks permissions for 1000 roles |
Pattern observation: The work grows roughly in proportion to the number of roles and their permissions.
Time Complexity: O(r * p)
This means the time grows with the number of roles (r) times the number of permissions per role (p).
[X] Wrong: "The query time depends only on the number of users."
[OK] Correct: The query focuses on roles and permissions, so the number of users does not affect the time directly.
Understanding how role-based access queries scale helps you design efficient permission checks in real applications.
"What if we added caching for user roles? How would the time complexity change?"
Practice
Solution
Step 1: Understand role-based access control concept
RBAC groups permissions into roles instead of assigning them individually to users.Step 2: Identify the main purpose in MySQL context
Assigning roles to users simplifies permission management and improves security.Final Answer:
To group permissions into roles and assign them to users -> Option BQuick Check:
RBAC = Group permissions + assign roles [OK]
- Confusing RBAC with password storage
- Thinking RBAC improves query speed
- Assuming RBAC is for backups
manager in MySQL?Solution
Step 1: Recall MySQL syntax for creating roles
The correct command to create a role isCREATE ROLE role_name;.Step 2: Match syntax with options
Only CREATE ROLE manager; uses the correctCREATE ROLEsyntax.Final Answer:
CREATE ROLE manager; -> Option AQuick Check:
CREATE ROLE = create new role [OK]
- Using MAKE ROLE instead of CREATE ROLE
- Using ADD ROLE which is invalid
- Using NEW ROLE which is not a MySQL command
CREATE ROLE analyst; GRANT SELECT ON sales TO analyst; GRANT analyst TO alice;
What permission does user
alice have on the sales table?Solution
Step 1: Analyze role creation and permission grant
The roleanalystis created and given SELECT permission on the sales table.Step 2: Check user role assignment
Useraliceis granted theanalystrole, so she inherits its permissions.Final Answer:
SELECT permission on sales -> Option AQuick Check:
User with role gets role's permissions [OK]
- Assuming user gets INSERT without grant
- Thinking user has no permissions without direct grant
- Assuming ALL permissions without explicit grant
GRANT SELECT ON employees TO 'john';
Why might this command fail when using role-based access?
Solution
Step 1: Understand role-based access best practice
In RBAC, permissions are granted to roles, then roles are assigned to users.Step 2: Identify why direct grant to user may fail
Granting permissions directly to users bypasses roles and may be restricted or discouraged.Final Answer:
Because permissions should be granted to roles, not directly to users -> Option DQuick Check:
Grant permissions to roles, assign roles to users [OK]
- Thinking SELECT is invalid permission
- Assuming username format is wrong
- Believing GRANT can't be used on tables
developer with INSERT and UPDATE permissions on the projects table, then assign it to user emma. Which sequence of commands correctly achieves this?Solution
Step 1: Create the role named developer
UseCREATE ROLE developer;to define the role.Step 2: Grant INSERT and UPDATE permissions on projects to the role
UseGRANT INSERT, UPDATE ON projects TO developer;to assign permissions.Step 3: Assign the role to user emma
UseGRANT developer TO emma;to give emma the role's permissions.Final Answer:
CREATE ROLE developer; GRANT INSERT, UPDATE ON projects TO developer; GRANT developer TO emma; -> Option CQuick Check:
Create role, grant permissions, assign role [OK]
- Granting permissions directly to user instead of role
- Using CREATE USER instead of CREATE ROLE
- Granting wrong permissions like SELECT instead of INSERT, UPDATE
Ready to prove it?
Pass the test and this pattern moves unknown
