The principles of database design, or, the Truth is out there

Seems like this article places too much emphasis on normalization, which is appropriate for many cases, but may be a huge cost and performance issue for requirements like reporting. You may probably need different kinds of schema and data storage structures for different requirements in the same application, which in turn may result in duplicated data, but results in acceptable trade offs.

That’s what I was taught as well. And even then I use it more as a rule of thumb

Putting aside performance implications, I get kinda irritated by having to do joins for basic queries all the time.

There are big disadvantages from choosing e g. 5th normal form: any changing in business requirements leads to a big rewrite and data conversion. Never seen successful projects choosing beyond 3rd/BCNF.

Then don't use a relational database. Sorry for being rude, but joins are an integral part of the relational model. If you want a KV store, you should use a KV store; if you want a Document DB, you should use a Document DB.

If you're doing reporting, create a reporting view that does all those joins once!

Sometimes I just wanna do some adhoc analysis and I need to do like four joins because some monkey decided to split everything into it's own table without thinking about the people that would actually have to use the db.

Your one-off analysis doesn’t trump the normal OLTP workloads.

I regularly have to do queries. I'm trying to understand my non-trivial product to figure out what work items will have, or have had, impact. Sometimes I'm in a meeting and need to do some real time analysis. My ability to understand and use the data is actually more important than a slightly higher database bill. And I thought we were ignoring the poor performance of normalization?