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

JavaBaby Membro desde: 14/11/2006 17:24:20 Mensagens: 76 Offline

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?

JavaBaby Membro desde: 17/01/2004 20:15:38 Mensagens: 77 Offline

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

mrbox wrote: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?

Cara, isso depende do que você pretende.
Se uma única tabela resolve todos os problemas (sem qualquer exceção), você pode usá-la.
Agora, as formas normalizadas dos bancos de dados foram definidas para melhorar a programação em bancos de dados.
Isso significa que você deverá ter um bom conhecimento em SQL para trabalhar com isto.

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.

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

drsmachado wrote: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 wrote:

drsmachado wrote: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.

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

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).

Notícias, artigos e o maior fórum brasileiro sobre Java