When does SQL database normalization become “stupid”?

I was recently in a heated discussion with my boss about a form I was building where the user ties an amount value to a “thing” (let’s call it a teapot), but he wanted the teapot field to be text whereas I thought it should be a drop-down with the names and IDs of the existing teapots… the user wasn’t allowed to create new teapot there, just assign an additional value for a new feature (which would be in its own table).

When I mentioned that if the user just types in the name of the existing teapot (whether they remembered it exactly or not or made a typo), and if someone else changes the name of the teapot (as has happened before, completely legitimately), the saved amount value record would be dereferenced from the teapot record, and then not applied during checkout… I said if I stored the key instead, changing the name would keep the reference.

He got upset and said that the value record will actually tie to another table record where just the teapot name is stored… which of course would suffer from the same dereferencing issue. I was told the references should be “normalized” through the unique auto-incrementing unchangeable IDs values, but he said “over-normalization is stupid”, and that “too many JOINs slows down the database”.

So I’m a bit exhasperated, and venting a little. Is this really stupid over-normalization, and when is assigning “foreign” keys by changeable name a good idea?