The Use Case
Let’s say we’re building a system to track maintenance sessions (WorkSession). Each session requires an approval (Approval) from a contractor before work can begin.

At first, we had a simple schema:

WorkSession

session_id (PK)

Approval

approval_id (PK)
session_id (FK)
contractor_name

Each Approval was linked directly to a WorkSession. But soon, a real-world need surfaced:

Sometimes, one approval covers multiple sessions.

But our database design didn't allow that. Instead, we had to duplicate approval records for each session — not ideal.

The Solution
We redesigned the schema to support many-to-many relationships using a join table:

WorkSession_Approval

session_id (FK)
approval_id (FK)

Now, a single Approval can be reused across multiple sessions.

In the UI, we added a feature for users to search and select existing approvals, reducing redundancy and simplifying workflows.

Why It Matters
Reusable data = fewer records, less clutter

Easier to maintain & more accurate

Reflects actual business logic

These kinds of small design shifts from tightly coupled to normalized lead to systems that scale better, adapt to real-world use cases, and are easier to evolve.