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.

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

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.

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.