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