Ele está fazendo do id_usuarios tanto chave estrangeira quanto chave estrangeira, como ele diz em:
"Então usuario_id em gestor e monitor são chaves primárias e ao mesmo tempo > estrangeiras do usuário" Até onde eu saiba isso não é boa prática e vai contra a normalização. Se não for, eu que lembrei errado das aulas. Enfim, os links lá dão uma boa base para a normalização de qualquer jeito. Att., 2011/3/29 Daniel Medina <[email protected]> > Eu entendi que ele tinha chegado a conclusão que poderia deixar os > atributos comuns às gestor/monitor em pessoas e colocar a chave estrangeira > de pessoas como chave primária em gestor/monitor. Desse jeito, não há > repetição de atributos e contempla a normalização... > > Copiar tudo é prejuízo. Por isso se faz essa espécie de herança (ou > especialização/generalização)... > > > > Em 29 de março de 2011 22:13, Erick Patrick > <[email protected]>escreveu: > > Daniel, >> >> Porém, duplicando somente a chave estrangeira, você duplica um único campo >> INT (duplicação necessária) enquanto duplicando todos os outros campos >> implicará em duplicação de campos varchars, text, etc, que acabam ocupando >> muito mais espaço (duplicação desnecessária) que um único campo INT, não >> é? Ou seja, ficar desse jeito é sim uma duplicação prejudicial. Logo terá um >> banco de dados demasiadamente inchado. >> >> Esse link da >> wikipedia<http://pt.wikipedia.org/wiki/Normaliza%C3%A7%C3%A3o_em_banco_de_dados>mostra >> passos para normalizar uma tabela. Perceberão que esse procedimento >> que falei, de colocar uma chave estrangeira em gestor/monitor, é basicamente >> o que ele explica para deixar a tabela na Primeira Forma Normal (1FN). Sei >> que não é a melhor fonte, mas é a primeira em resultados do Google, e mostra >> que uma simples busca por "normalização de banco de dados" já dá algum >> resultado. >> >> Indo mais a fundo, pode-se chegar a esse >> link<http://www.luis.blog.br/normalizacao-de-dados-e-as-formas-normais.aspx>, >> mais completo e que explica melhor como funciona a Normalização de tabelas, >> bastando ver os links relacionados ao final do artigo, que levam para >> continuações e/ou outras explicações. >> >> Att., >> >> >> >> >> >> >> 2011/3/29 Daniel Medina <[email protected]> >> >>> Até onde li e vi sobre normalização, a maneira que o Tiago concluiu é a >>> maneira mais correta de fazer uma herança no MySQL. >>> >>> Colocando a chave usuario_id somente como chave estrangeira, você vai ter >>> a necessidade de criar uma chave primária para gestor/monitor. >>> >>> E colocar a chave estrangeira como chave primária em gestor/monitor é tão >>> duplicação como qualquer outro relacionamento. Ou seja: não chega a ser >>> duplicação... >>> >>> Daniel >>> >>> Em 29 de março de 2011 20:50, Erick Patrick >>> <[email protected]>escreveu: >>> >>> Mas tu não precisa ter os mesmo campos da tabela usuário nas gestor ou >>>> monitor. Coloca essa usuario_id como chave estrangeira, somente, e na hora >>>> de buscar os dados do pessoal, só fazer um *join* entre a gestor/monitor e >>>> usuário, dai tu vai ter todos os campos sem precisar duplicar os dados. >>>> >>>> Eu faço desse jeito. Se não me engano, faz parte de uma das regras de >>>> *normalização* (evitar duplicação desnecessária). >>>> >>>> Att., >>>> >>>> -- >>>> Erick Patrick >>>> Sent with Sparrow <http://www.sparrowmailapp.com> >>>> >>>> On Tuesday, 29 de March de 2011 at 5:54 PM, Tiago Davi wrote: >>>> >>>> Olá estou procurando entender o conceito de normalização que por sinal é >>>> muito útil. >>>> >>>> Erick por enquanto meu modelo está assim recebendo a chave estrangeira >>>> do usuário e essa como chave primária. >>>> >>>> Então usuario_id em gestor e monitor são chaves primárias e ao mesmo >>>> tempo estrangeiras do usuário pois eles deverão ter todos os campos que >>>> tenho na tabela usuario além dos seus campos específicos. >>>> >>>> Obrigado! >>>> >>>> Em 29 de março de 2011 17:28, Erick Patrick <[email protected] >>>> > escreveu: >>>> >>>> Tiago, >>>> >>>> Eu colocaria uma chave estrangeira em Gestor e Monitor apontando para o >>>> id do respectivo usuário na tabela Usuário. >>>> >>>> Att, >>>> >>>> -- >>>> Erick Patrick >>>> Sent with Sparrow <http://www.sparrowmailapp.com> >>>> >>>> On Tuesday, 29 de March de 2011 at 5:19 PM, Tiago Davi wrote: >>>> >>>> Olá gostaria de tirar uma dúvida com os DBAS de plantão...rs >>>> >>>> O que seria melhor? >>>> >>>> Tenho uma tabela de *usuario* com nome, email, senha etc. >>>> >>>> Tenho uma tabela *gestor* que também tem nome, email e etc e uma outra >>>> tabela *monitor* que também tem nome, email e etc. >>>> >>>> Montei meu banco fazendo com que a tabela *gestor* e a tabela >>>> *monitor*tenham uma foreignkey de >>>> *usuário* sendo ela a própria chave primária dessas tabelas, pois >>>> gestores e monitores não passam de usuários certo? >>>> >>>> Gostaria de saber se essa é uma boa abordagem tentando simular herança >>>> no MySQL e NÃO recriar os mesmos campos em cada tabela. >>>> >>>> Senão teria que colocar nome e etc em todas as tabelas... na verdade >>>> gostaria de seguir a melhor abordagem para um caso como esse. >>>> >>>> Obg. >>>> >>>> -- >>>> Tiago Davi - Desenvolvedor Web. >>>> http://tiagoaspnet.blogspot.com >>>> >>>> >>>> _______________________________________________ >>>> [email protected] >>>> http://www.codeigniter.com.br >>>> http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br >>>> >>>> --------------------------- >>>> Oportunidade de negócio >>>> http://www.franquiasargohost.net >>>> --------------------------- >>>> >>>> >>>> >>>> _______________________________________________ >>>> [email protected] >>>> http://www.codeigniter.com.br >>>> http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br >>>> >>>> --------------------------- >>>> Oportunidade de negócio >>>> http://www.franquiasargohost.net >>>> --------------------------- >>>> >>>> >>>> >>>> >>>> -- >>>> Tiago Davi - Desenvolvedor Web. >>>> http://tiagoaspnet.blogspot.com >>>> >>>> >>>> _______________________________________________ >>>> [email protected] >>>> http://www.codeigniter.com.br >>>> http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br >>>> >>>> --------------------------- >>>> Oportunidade de negócio >>>> http://www.franquiasargohost.net >>>> --------------------------- >>>> >>>> >>>> >>>> _______________________________________________ >>>> [email protected] >>>> http://www.codeigniter.com.br >>>> http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br >>>> >>>> --------------------------- >>>> Oportunidade de negócio >>>> http://www.franquiasargohost.net >>>> --------------------------- >>>> >>>> >>> >>> >>> -- >>> Daniel Medina >>> >>> _______________________________________________ >>> [email protected] >>> http://www.codeigniter.com.br >>> http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br >>> >>> --------------------------- >>> Oportunidade de negócio >>> http://www.franquiasargohost.net >>> --------------------------- >>> >>> >> >> _______________________________________________ >> [email protected] >> http://www.codeigniter.com.br >> http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br >> >> --------------------------- >> Oportunidade de negócio >> http://www.franquiasargohost.net >> --------------------------- >> >> > > > -- > Daniel Medina > > _______________________________________________ > [email protected] > http://www.codeigniter.com.br > http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br > > --------------------------- > Oportunidade de negócio > http://www.franquiasargohost.net > --------------------------- > >
_______________________________________________ [email protected] http://www.codeigniter.com.br http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br --------------------------- Oportunidade de negócio http://www.franquiasargohost.net ---------------------------
