Normalização de Banco de Dados: 1FN, 2FN, 3FN, 4FN, etc

Até a 4FN já vi modelado…mas na maioria dos casos para na terceira mesmo.

mrbox:

Olá pessoal,

Estive estudando normalização de banco de dados (1FN, 2FN, 3FN, etc) e gostaria de saber até que forma normal é usada na prática.
A Teoria é muito interessante, mas na prática, por ex: a 4FN gera mais tabelas. Isso me parece um complicador na hora de realizar um INSERT, UPDATE, etc.

Nos sistemas que vocês trabalham no dia a dia, até quais FNs são realmente aplicadas no banco?

Particularmente eu sou um defensor da normalização. Fica mais limpo, mais funcional compreender a estrutura do banco.
Agora, se você quer economizar uns joins para evitar isto…
Boa sorte.

drsmachado:

Particularmente eu sou um defensor da normalização. Fica mais limpo, mais funcional compreender a estrutura do banco.
Agora, se você quer economizar uns joins para evitar isto…
Boa sorte.

Depois de algumas centenas de milhões de registros em transacional (e falando somente de uma tabela), eu vou ficar surpreso com quem continuar sendo purista. A equipe de DW que o diga.

Bruno Laturner:

drsmachado:

Particularmente eu sou um defensor da normalização. Fica mais limpo, mais funcional compreender a estrutura do banco.
Agora, se você quer economizar uns joins para evitar isto…
Boa sorte.

Depois de algumas centenas de milhões de registros em transacional (e falando somente de uma tabela), eu vou ficar surpreso com quem continuar sendo purista. A equipe de DW que o diga.

E a solução para isto é a gambiarra?
Ou você já usa um banco orientado a objetos?
Aliás, conhece um framework chamado Hibernate?

Desculpa de aleijado é muleta, meu camarada.
Quem acha que tudo se resolve com um “jeitinho” é que acaba comprometendo performance e estrutura.
Vejo um monte de pessoas atropelarem os patterns e as boas práticas em troca de agilidade e coisas do gênero, mas, sempre que vejo um sistema cheio de gambiarras eu consigo entender por que o mercado de TI está fadado à ter profissionais medíocres e salários pífios. Afinal, um bom profissional não aceita qualquer salário.

É sempre mais fácil fazer de qualquer jeito do que estudar, compreender e aplicar as regras e boas práticas.

Desnormalizar tabelas não é gambiarra. Não sei como orientação a objetos ou Hibernate vão te salvar a fazer relatórios em bases de dados imensas. Um map-reduce até vá, mas o banco já tá satisfazendo todas as outras milhares de necessidades da empresa, menos a tua.

Eu também adoro um design limpo, compreensível, tudo lindo, mas também tem horas que é preciso escovar bits. É feio, é chato, e não é POG.

O que digo é para não demonizar essas práticas. Não estou falando de desnormalização como se fosse normal, ela é certamente a exceção, perto do último caso, mas também não a demonize. É bem capaz de não precisar chegar no última caso, talvez seja viável esperar 6 horas para que o relatório de um mês esteja pronto, e você tem que gerar 2 anos destes.

[/advogado do diabo]

De qualquer forma, também tenho que concordar contigo que design bom, além das milhares de vantagens, também é zilhões de vezes mais performático que design ruim. O que mais ouço por aí são casos de queries que demoravam 24 horas para terminar, que depois de uma refatoração foi para 15 segundos(moral da história, query builders geralmente são um lixo), e de empresas que tomavam prejuízo na casa dos milhões por não fechar o billing do mês, e que hoje o fazem em 6 horas (moral: contratar os melhores profissionais do mercado sempre sai mais barato).