Fui educado na velha escola - onde aprendemos a projetar o esquema do banco de dados ANTES da camada de negócios do aplicativo (ou usando o OOAD para todo o resto). Eu fui muito bom em projetar esquemas (IMHO :) e normalizei apenas para remover redundância desnecessária, mas não onde isso afetava a velocidade. Mas principalmente não era.
Com o advento de algumas estruturas ORM como o ActiveRecord do Ruby ou o ActiveJDBC (e algumas outras que não me lembro, mas tenho certeza de que há muitas), parece que elas preferem ter uma chave substituta para todas as tabelas, mesmo que algumas tenham chaves primárias como 'email' - quebrando 2NF diretamente. Ok, eu não entendo muito, mas isso me dá nos nervos (quase) quando alguns desses ORMs (ou programadores) não reconhecem 1-1 ou 1-0 | 1 (ou seja, 1 a 0 ou 1). Eles estipulam que é melhor ter tudo como uma grande mesa, não importa se há uma tonelada de nulls
"sistemas de hoje em dia", é o comentário que eu ouvi com mais frequência.
Concordo que as restrições de memória tiveram uma correlação direta com a normalização (também existem outros benefícios :), mas hoje em dia com memória barata e máquinas quad-core, o conceito de normalização de banco de dados é deixado apenas para os textos? Como DBAs você ainda pratica a normalização para 3NF (se não for BCNF :)? Isso importa? O design do "esquema sujo" é bom para os sistemas de produção? Como se deve defender a normalização "se" ainda é relevante.
( Observação: não estou falando dos esquemas em estrela / floco de neve do datawarehouse que têm redundância como parte / necessidade do design, mas sistemas comerciais com um banco de dados de back-end como o StackExchange, por exemplo)