Maybe you referenced the wrong post, but that one completely misunderstands what normalization even is (he believes it applies only to single tables), then compounds his error by claiming surrogate keys "make normalization more difficult". Total nonsense.

The reason the "surrogate vs. natural" debate even exists is because there is no one right answer in all situations. It depends not only on the data being modeled, but a whole host of other factors: whether you're OLAP vs. OLTP, query vs. update ratio, and even things like code maintenance costs.

Surrogate keys often require additional indexes. And, because you're eliminating natural columns in child tables as join keys, additional joins as well. You may need to define additional unique constraints because your key no longer enforces business uniqueness. Finally, they make your tables slightly larger, which for very narrow tables, may have performance and space implications. They used to be prone to index contention issues in some RDBMs (though modern products have pretty much entirely corrected this).

That said, in **practice** these caveats are usually (but not always) minor, often to the point of insignificance. Surrogate keys reduce cascading updates and other annoying problems. They can save space when a natural key is very wide. But most importantly, they tend to make a system more resilient to changes in business logic. In nearly all firms, programmer time is a resource far more valuable than cpu cycles or disk i/o's.

The rule of thumb I always tell junior developers is, if you can clearly and concisely state why a natural key should be preferred in a specific instance -- use it. If not, then a surrogate key should be your default.