[firebase-br] Normalização de Banco de dados

[Jhosef Marks]

Trabalhei em um empresa que tinha tabelas que tinham até 6 campos como
chave, os wheres eram muito extensos...

Tinha grade de produtos, então era o codigo do item, mais variação 1, mais
variação 2, mais cor, mas codigo da tabela de venda, mais codigo do item de
venda, mais alguma coisa.... pedido era triste de fazer SQL...
huauahuhuahuahuhua

Att,

*Jhosef Marks de Carvalho*
*Blog: **http://www.jhosefmarks.com.br* <http://www.jhosefmarks.com.br>*
Jesus está voltando

*
*"E se o meu povo, que se chama pelo meu nome, se humilhar, e orar, e buscar
a minha face e se converter dos seus maus caminhos, então eu ouvirei dos
céus, e perdoarei os seus pecados, e sararei a sua terra." (2 Cr 7:14) *



Em 30 de setembro de 2010 07:52, Alysson Gonçalves de Azevedo <
agalysson em gmail.com> escreveu:

> Tb uso 1 campo para PK... para outras validações, eu crio chaves unicas e
> coisas assim...
> a vantagem mesmo eh que vc pode fazer select simples, onde campochave = x,
> ao inves de onde campopai = x and campochave = y and ...
>
> e criando simples fks, vc resolve dependencias pai x filho sem
> necessariamente precisar que ela esteja na pk...
>
> Alysson Gonçalves de Azevedo
> (11) 8491-7730
>
> (\(''^_^ )/)
>
> "Pobre vive dizendo que não tem nada, mas quando vem a enchente, ele sai
> gritando: -Perdi tudo!!!"
>
>
>
>
> Em 29 de setembro de 2010 17:06, Jhosef Marks <jhosef em gmail.com> escreveu:
>
> > Sou a favor de usar um campo só tbem, se tiver necessidade de validar 2
> ou
> > 3
> > campos, cria um indice...
> >
> > Att,
> >
> > *Jhosef Marks de Carvalho*
> > *Blog: **http://www.jhosefmarks.com.br* <http://www.jhosefmarks.com.br>*
> > Jesus está voltando
> >
> > *
> > *"E se o meu povo, que se chama pelo meu nome, se humilhar, e orar, e
> > buscar
> > a minha face e se converter dos seus maus caminhos, então eu ouvirei dos
> > céus, e perdoarei os seus pecados, e sararei a sua terra." (2 Cr 7:14) *
> >
> >
> >
> > Em 29 de setembro de 2010 16:28, Alexandre Sousa
> > <dave.malkavian em gmail.com>escreveu:
> >
> > >  É uma prática comum usar somente um campo na PK, apesar disso ir
> contra
> > a
> > > teoria de modelagem, onde quando existe uma relação identificada (ou
> > relação
> > > forte) entre entidades, os campos chaves da entidade pai devem fazer
> > parte
> > > da chave da entidade filha. Isso pode ser percebido em qualquer
> > ferramenta
> > > de modelagem, onde ao inserir esse tipo de relação sempre são levados
> os
> > > campos da entidade pai. (
> > > http://www.dhdursoassociates.com/database-glossary-2.html#identifying)
> > >
> > > Claro que na prática isso gera um custo em manter essa estrutura, pois
> > > qualquer alteração, relatório, etc, deve levar em conta todos os campos
> > que
> > > fazem parte da PK. Fora a perda de performance ao fazer o SGBD validar
> > todos
> > > os campos.
> > >
> > > Minha opinião é que se preze pela performance e baixa manutenção, ou
> > seja,
> > > 1 único campo crescente sendo a chave primária.
> > >
> > > []'s
> > > Alexandre Sousa
> > >
> > > Em 29/09/2010 16:18, DanielN escreveu:
> > >
> > >  Pessoal, boa tarde
> > >> estamos re-estruturando nossos sistemas, e um dos pontos a serem
> > >> avalizados é a estrutura do banco de dados, com isso surgiu uma
> dúvida,
> > onde
> > >> gostaria da opinião de vcs:
> > >> hoje usamos a chave primária da tabela para identificar um registro,
> em
> > >> muitos casos utilizamos dois ou três campos como chave para isso.
> > >> mas alguma pessoas dizem que deveria ter um campo único para este fim,
> > um
> > >> id que irá identificar o registro.
> > >> alguem tem experiência com os dois tipos de estrutura de bancos para
> me
> > >> dizer quais os benefícios de se utilizar um id único ao invés de
> vários
> > >> campos na chave primária?
> > >>
> > >> um detalhe que acho que deve ser importante, nosso banco de dados é de
> > um
> > >> ERP, onde existem mais atualizações de dados do que emissão de
> > relatório,
> > >> mas os relatórios sempre envolvem muitas tabelas para chegar nas
> > informações
> > >> necessárias.
> > >> e o volume de dados sempre é grande por tabela, coisa de no mímino
> > 100000
> > >> por tabela, na maioria de nosso clientes.
> > >>
> > >> Grato
> > >> Daniel Nicoletti
> > >>
> > >>
> > >> ______________________________________________
> > >> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> > >> Para saber como gerenciar/excluir seu cadastro na lista, use:
> > >> http://www.firebase.com.br/fb/artigo.php?id=1107
> > >> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> > >>
> > >
> > >
> > > ______________________________________________
> > > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> > > Para saber como gerenciar/excluir seu cadastro na lista, use:
> > > http://www.firebase.com.br/fb/artigo.php?id=1107
> > > Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> > >
> > ______________________________________________
> > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> > Para saber como gerenciar/excluir seu cadastro na lista, use:
> > http://www.firebase.com.br/fb/artigo.php?id=1107
> > Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> >
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>