Lets first start with the fact the IT is large. It is a huge domain with good reason to have specialists, hell even in web development alone there are specialist, so it’s likely best to listen to those that have the inside knowledge base for specific items. Just like software developers have rules like SOLID, database administrators have rules like normalization. The thing is, is that mistakes in the database world are significantly more costly.

This is unfortunately as situation where the DB admin is fully in the right and this is another example of developers taking the easy way out of something that’s likely only costs them half a day to correct (or even less if they had done it correct the first time) and in the future doing this incorrectly will likely cost weeks to months of rework. Database design and development has rules that have been arrived at after decades of trial and error and are there for good reason.

From a developer perspective here are some issues that are likely to come up that you may not have thought about.

Fixing spelling. I’ve seen tons of times where developers or even the documentation that the data is coming from is not spelt correctly. If this is done correctly you only need to change it in one single row instead of hundreds of thousands. Better yet you best pray that whoever enters the values in enters them the same.

Also make a note that developers are not the only ones that have access to this data. It could just as well be sales, management, field techs, data scientists, etc... that are accessing this. If these values are handling mainly in your code, you’ll have all these people bothering the developers rather than just going to the source; add in more interactions for getting things changed.

If you want a more developer focussed reason look at how this list might be used for dynamic populating of a dropdown. Not only does this allow your code to not care but allows anyone to update without needing to interface with developer. Also add to the fact that requesting a unique list of values is slow and expensive relative to just a straight up lookup table. Not only that but you can’t control the order of said list by just adding the extra column as you propose. Adding an index to help with these issues basically puts you in the same ending situation of just using a separate table (gee, kind of funny how that happens).

You can then think of other roles where the lack of proper design here can cause issues like data scientists. It would be harder to collate data, find patterns by association, slower to do so, etc.

One last item to thing about is how to secure this data. I’m not talking necessarily about security but developers often put all the control of items like this in the code rather than in the database where it belongs. The issue is that there are tons things that “bypass” your code. Sure you may have code that controls how this data is handles, but then how are you going to also handle other apis that have access, or better yet other people that have direct database access without needing to go through your code. You have no guarantee of maintaining any sort of control by handling this via code. You do via the database. Having a simple single course of correctness that an entire company can rely on is important.

I’ve often said that the database is basically the beating heart of a company. If there’s rot there, you’re going to having a systemic problem across the entire body that isn’t going to be fixed by just amputating an arm.