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