Chapter 3
When the same artist appears five times
At first, Gary doesn’t notice the problem.
The spreadsheet is working.
He can search for records.
He can answer calls quickly.
That was the goal.
But as the list grows, small things start to stand out.
The spelling problem
Gary searches for an artist.
The results surprise him.
The same name appears more than once.
Sometimes with a middle initial.
Sometimes without.
Sometimes with a spelling he doesn’t remember using.
All of them clearly refer to the same artist.
Gary sighs.
This isn’t a system problem.
It’s just messy data.
Manual cleanup feels responsible
So Gary does what feels reasonable.
He fixes it.
He corrects spellings.
He standardizes names.
He makes everything consistent.
The table looks better.
Searching works again.
For a while.
The same work keeps coming back
A few days later, Gary adds new records.
The same artist appears again.
Spelled slightly differently this time.
Not wrong — just different.
Gary notices it later.
He fixes it again.
Then again.
And again.
Nothing is broken.
But the same correction keeps repeating itself.
Sam notices the pattern
Sam stops by while Gary is cleaning up the sheet.
Gary explains the situation.
“I just need to be more careful,” he says.
“If I spell things the same way, it’s fine.”
Sam nods.
Then asks:
“Why does the same name need to be written more than once?”
One table doing two jobs
Sam points at the spreadsheet.
“Right now,” he says,
“this table is doing two different things.”
Gary looks at the rows.
“One job is listing records,” Sam continues.
“The other job is describing artists.”
Gary hasn’t thought about it like that.
He just sees rows and columns.
A small structural change
Sam suggests something simple.
“Keep this sheet for records,” he says.
“But make a second sheet for artists.”
One row per artist.
Each artist written once.
Now, instead of writing the artist’s name directly in the record list,
each record points to an artist in the other sheet.
Gary studies the two sheets.
Then frowns.
“But how does it know?”
Gary looks back at Sam.
“But how does this actually work?” he asks.
“How does a record know which artist it belongs to?”
Sam nods. He was expecting the question.
“Each artist gets their own row,” he says.
“And that row gets its own number.”
Gary raises an eyebrow.
“A number?”
“Just an internal one,” Sam says.
“Something the system uses. You don’t have to care about it.”
He points to the artist sheet.
“This row is that artist.
No matter how the name is written.
No matter how many records reference it.”
Then he points back to the record list.
“Here, instead of writing the artist’s name,
you store that number.”
Gary pauses.
“So every record just points to the same artist row?”
Sam nods.
“One artist.
One place to fix it.
Every record connected automatically.”
Gary leans back.
“So the name isn’t copied anymore.”
“No,” Sam says.
“The connection is.”
The effect is immediate
Gary fixes an artist’s name.
It updates everywhere.
He doesn’t search the table.
He doesn’t wonder if he missed a row.
For the first time,
fixing something feels final.
What changes (quietly)
Gary doesn’t think of this as modeling.
He thinks of it as:
“Finally having one place to fix things.”
But something important has changed.
The spreadsheet no longer just stores information.
It now expresses a relationship.
And relationships behave differently than columns.
Continue reading
In the next chapter, Gary runs into a different kind of problem.
Some records clearly belong to more than one artist.
Some artists appear on many records.
Gary tries to make it fit anyway.
By choosing one artist.
By adding extra columns.
None of it feels quite right.
The problem isn’t missing information.
It’s that the connection itself doesn’t fit in a single row.