Is database normalization still \"the thing?\"
When I studied during a databases course we were taught all levels of normalization and were said that we must always
NoSQL is not a silver bullet: it is simply a technology that may provide a far better fit for for certain circumstances. For relationally-shaped data, the RDBMS is not going away any time soon.
A rule of thumb "JOIN's are Expensive on Processing Power". I use is when creating a database for a project large or small. Tables that hold data such as usernames, addresses etc should always be normalised as they are accessed less recently how you where taught using the kind of examples taught. Now in recent years web2.0 data, apps, mobile services etc. have taken in fact a different type of data which with the abundance of memory code even lower, it can save processing power to keep them all on the same "table" not normalising it.
yes, for a transactional system always normalise, or chances are you're going to have major headaches further down the road. For a database that will be used for reporting/OLAP denormalising the schema can be very helpful.
It depends on what type of application(s) are using the database.
For OLTP apps (principally data entry, with many INSERTs, UPDATEs and DELETES, along with SELECTs), normalized is generally a good thing.
For OLAP and reporting apps, normalization is not helpful. SELECT queries will run much more quickly against a denormalized schema, which could be achieved with views.
You might also find some helpful information in these very popular similar questions:
Should I normalize my DB or not?
In terms of databases, is “Normalize for correctness, denormalize for performance” a right mantra?
What is the resource impact from normalizing a database?
How to convince someone to normalize a database?
Is it really better to use normalized tables?