Or you just avoid all that hassle and have some duplicates.

I have never seen a properly denormalized table. In practice you will get a "historically grown" system way to often and doing anything like that will break things.

The whole article seems to be quite academic from my personal experience a textbook normalized database is slow beyond belief (i did exactly that once and we had to revert it back).

Or better yet, since you don't care about your data anyways, just don't bother storing it. Infinitely scalable and always blazingly fast.

>I have never seen a properly denormalized table

Do you mean normalized? There's no such thing as "properly" denormalized, anything that is not normal is denormalized.

>The whole article seems to be quite academic from my personal experience a textbook normalized database is slow beyond belief (i did exactly that once and we had to revert it back).

I've seen lots of people say that, but then consistently found those same people don't actually know what the normalization rules are, and all they did was create a different denormalized database that happened to have poor performance for the queries they were using.

For an existing application I personally prefer changing the index type, partitioning the table or tuning DB parameters first. It's far less risky because you don't need to change a single query and it's transaprent to the application. Sure if you cannot get the desired perfomance by tuning the RDBMS than you need to consider changing the way how the tables are modelled. From my experience, usually normalizing it one step furhter improves the performance, at least for OLTP use cases.