Essa otimização prematura significa que você não deve otimizar nada. Eu vi bancos de dados terrivelmente ruins porque ninguém queria considerar o desempenho (crítico para qualquer sistema de banco de dados) no design, pois isso era uma otimização prematura do que qualquer outro problema de design de banco de dados. Lixo, existem assassinos de desempenho conhecidos, pare de usá-los como sua primeira escolha.
Outro mito, é muito difícil refatorar o banco de dados. Não, mas você deve considerar como fazer a refatoração na fase de design para fazê-lo de forma eficaz. E, BTW, quanto mais você esperar para corrigir esse problema irritante de desempenho baseado em design, mais difícil será corrigir.
Outro mito ruim, o design do banco de dados deve refletir os princípios de POO. Não, os bancos de dados são projetados para trabalhar com conjuntos e não com princípios de POO. Algumas coisas de POO causarão problemas horríveis de desempenho e outras são muito tolas em termos de banco de dados.
Por fim, você deve impor a integridade dos dados no aplicativo. Os bancos de dados vão durar mais do que o aplicativo e perderiam as regras quando o aplicativo for substituído, vários aplicativos os acessarão e, muitas vezes, haverá a necessidade de executar consultas diretas para corrigir coisas que não passam pelo aplicativo. Eu nunca vi um banco de dados que se recuse a impor a integridade dos dados no banco de dados que possui bons dados.