As you can see in article, real life scenario 2 is more complicated than the one table. It consists of 4 tables (in my case). Based on 4 tables you DO NOT HAVE MORE THAN 1 LEVEL of dependency. And codes are separated by groups. Plus, I store ONLY GENERIC codes in the structure. The codes that are not company specific. Company specific codes are in their own tables based on scenario 1. This allows reuse generic codes and separates them from user specific ones. If you have one database or one big data warehouse it may be irrelevant. But if server has 200+ databases it will be much less overhead to keep generic code tables into on separated database. In my case, 2-3 new databases created in server weekly. All of them have the same generic codes and it will be complete "madness" try to synchronize them when changes necessary.

Each design should be choosen carefully for each specific case! As always each one have pluses and minuses. It is mean choose ideas carefully for you database scenario.