[koliber]

> In a normalised database there will only be one phone number for multiple uses.

No! Normalization does not mean keeping only one copy of each piece of data, regardless of category and context. I see this behavior all the time in junior and even some senior devs, both in databases, and when they code.

A piece of information has a type, but it also has a context. A 2FA phone number is different than a marketing contact phone number. It should never be normalized into just one field.

My favorite example of this is people re-using a constant in multiple places in code just because it happens to have the same value. Imagine you have a constant defined as `USER_DISPLAY_AS = 'first_name'`. Then, somewhere, you are building sorting and want to be able to sort by first name or last name. You notice you already have a constant that contains a value 'first_name', so you use it. Not you have tied two completely different things together in your code because you thought you are being DRY.

[rorykoehler]

I don't disagree with you on the type issue but you can see in a large organisation how this would easily fall through the cracks. It's also entirely plausible that an intern came up with the sms notification idea and it wasn't caught in code review. I don't really subscribe to Hanlon's razor but in this context I can understand how it could happen quite easily.

[koliber]

This is a type of error that is often found in code and data modeling. I haven't come across a name for it yet. It most definitely can and does fall through the cracks, in small, medium, and large organizations. It is a code smell and should be eliminated whenever it starts happening. However, it is often quite subtle, and a developer's ego is often stronger than the explanation for why it should not be done that way.

I shall dub it "Krystian's Overoptimistic Denormalization Error", or KODE for short.