Oran spent two weeks doing something that felt like not working.
He sat with the warehouse team during morning receiving. He watched Ms. Lin process purchase orders after lunch. He stood on the factory floor while the supervisor assigned shifts. He even attended the Monday management meeting — the only cat in a room full of dogs — and took notes.
He didn't write a single line of code.
But he filled an entire notebook.
Patterns started showing up.
Every department had the same complaint in different words:
- Warehouse: "We shouldn't see pricing."
- Finance: "We need to know who approved what."
- Production: "The supervisor can assign shifts, but only the manager can approve overtime."
- Sales: "I need to see orders but not cost breakdowns."
Oran stared at his notebook. All of these were the same problem.
Who can do what. And who said they could.
He went back to his AI tools and prompted: "best way to handle permissions in a web application."
The AI gave him a middleware snippet with hardcoded role checks. if role == 'admin'. if role == 'manager'. The same pattern he'd already built. The same pattern that broke.
So Oran did something he hadn't done before. He closed the AI and opened Google. Then a textbook. Then a blog post from someone who had clearly been through the same pain.
He found RBAC.
Role-Based Access Control. Not a framework. Not a library. A design pattern. And at its core, a data model — five tables in a relational database.
users. roles. permissions. And two mapping tables to connect them.
The idea was simple: permissions are data, not code.
You don't write if role == 'warehouse_lead' in your application. You store warehouse_lead → inventory:read, inventory:update in the database. The app asks one question: does this user have this permission? A single SQL query answers it.
This changed how Oran thought about everything.
Suddenly, Duke's requirement — "my guys shouldn't see pricing" — wasn't a special case. It was a permission row: warehouse_staff role gets inventory:read but not pricing:read.
Ms. Lin's approval chain? The granted_by and granted_at columns on the role assignment table. Every permission change is a row. Every row is an audit record.
The production supervisor approving shifts but not overtime? Two different permissions: shifts:assign and overtime:approve. One role has both. One role has only the first.
No if/else. No spaghetti. Just data.
But here's what really clicked for Oran. The 5-table model wasn't just a technical solution. It was a communication tool.
He drew the schema on a whiteboard and walked Ms. Lin through it. "This table is your list of people. This table is the list of roles — think of them as job titles for system access. This table is every action the system can do. And these two tables connect them."
Ms. Lin nodded. "So if I want to give the new accountant the same access as me, you just..."
"Copy your role assignments. One query. No code change."
"And I can see who has what access?"
"One report. Anytime."
Ms. Lin smiled for the first time since Oran started.
That night, Oran rebuilt the permission layer. AI helped him write the SQL faster — but the design was his. Every table, every column, every constraint came from the notebook he filled during those two weeks of watching and listening.
He was learning a lesson most developers take years to learn:
SQL isn't just storage. It's where business logic lives. The approval threshold ($5,000) is a value in a table. The permission boundary is a row in a mapping table. The audit trail is a timestamp on every change.
When business rules live in the database, they survive framework migrations, language rewrites, and developer turnover. They survive even when the only dev at the company is one orange cat.
Next episode: The boss asks Oran to present the system to the whole company. Oran learns that explaining a database to non-technical people is a skill nobody taught him — and maybe the most important one.
Oran's journey is brought to you by SysLayer — practical backend guides for developers who build real products.
Top comments (0)