Normalizacao de banco de dados

Foxanger · 5 de setembro de 2013

Tenho uma seguinte duvida.

Qual a melhor forma de normalizar um banco de dados

Pelo que andei vendo na web , o certo seria assim

Ex:

Mas quando eu for fazer uma consulta por cliente vai me retornar varias linhas do mesmo cliente.

E se eu colocasse na propria tabela de clientes colunas que especificassem fone1, fone2, fone3? Não sairia mais em conta e bem mais pratico?

Erciley Junior · 5 de setembro de 2013

Ao meu ver, o mais correto é uma tabela separada só com os telefones, mas teoricamente, dependendo a forma que você faça, retornaria várias vezes o mesmo cliente.

O mais prático, é colunas na tabela cliente para informar vários telefones, o problema disso é que sempre que precisar de um novo, terá que criar mais uma coluna, mais outra, etc, ou seja, fica uma b*sta ^^

Crie a tabela telefones, e neste cadastro, marque um como o principal de cada cliente

quando fazer JOIN para pegar essa informação, você irá fazer

SELECT CL.ID_CLIENTE
      ,CL.NOME
      ,TEL.TELEFONE
FROM tabela_cliente AS CL
LEFT OUTER JOIN tabela_telefone AS TEL ON TEL.ID_CLIENTE = CL.ID_CLIENTE 
                                      AND TEL.PRINCIPAL = 'SIM';

Essa é a melhor forma, ao MEU ver.

fabianomf1974 · 18 de outubro de 2013

Apenas um comentário, já que a solução do Erciley é uma boa solução e eu também costumo usar desta forma.

Um equívoco comum é achar que toda tabela precisa de uma chave principal, como a sua tabela de telefones tem o campo IdClienteTelefone que parece ser a chave principal desta tabela.

As tabelas que devem ter as chaves principais são apenas as tabelas primárias, as tabelas principais. As tabelas relacionadas têm que ter apenas as chaves estrangeiras (chaves transpostas) que servem justamente para a função de "relacionar" as tabelas principais e suas tabelas relacionadas (os clientes com os seus telefones).

Certamente você não vai fazer uma consulta pelo campo IdClienteTelefone, parece não fazer sentido.

Se você puder, exclua esse campo (e outros como esse) e diminua o tamanho do seu banco de dados, tráfego na rede, operações de e/s no hd onde se encontra o banco de dados, etc.

DiF · 18 de outubro de 2013

ao meu ver.. aquele campo só serve para a contagem de linhas.. mesmo eu deixaria como está.

fabianomf1974 · 18 de outubro de 2013

E estaria errado. Não estaria normalizado.

Pense bem, para quê você quer saber quantos telefones têm cadastrados na sua base de dados? Qual é a utilidade prática?

"- Que louco! Tenho 1000 telefones cadastrados. Xá pegá um e ligar para ver o que acontece."

Entendeu?

Muitas vezes usamos uma chave primária para substituir uma chave composta muito grande, com três ou mais chaves estrangeiras e/ou campos que compõem essa chave composta para um terceiro relacionamento, mas simplesmente pela praticidade na modelagem e programação, às vezes eu lanço mão desse recurso. E, claro, também está errado.

Erciley Junior · 18 de outubro de 2013

"- Que louco! Tenho 1000 telefones cadastrados. Xá pegá um e ligar para ver o que acontece."

Confesso que comecei a dar risada aqui, hehehehe ^^

Olha, alguns sistemas utilizamos arquivos DBF ainda, e com DBF, se usa excessivamente o RECNO.

RECNO é um número de registro para cada arquivo (arquivo seria as tabelas do mysql), ou seja, trabalhando com DBF, além das "chaves estrangeiras" e índices que existem, existe também o RECNO, que é uma numeração única de cada registro de cada arquivo (tabela).

Bom, entendo que esse campo não tem finalidade alguma realmente neste caso, mas também não vejo tanto mal em deixá-lo.

Talvez por ter trabalhado e ainda trabalhar com DBF, gosto dessa ideia de um campo INCREMENTAL em cada arquivo (facilita aquelas deleções manuais ^^). Mas é apenas minha opinião devido a praticidade em alguns casos, mas o que foi dito não deixa de ser verdade, é mais um espaço utilizado no HD, não é de suma importância, talvez seja errado, etc....

fabianomf1974 · 21 de outubro de 2013

Verdade, lá nos idos do dbase e clipper nós fazíamos muito uso de recno(), mas os "relacionamentos", que eram feitos no próprio programa com um Set Relation To, não eram lá um primor de confiabilidade, rs, obrigando-nos a tomar certas precauções, e a função recno() trazia o número do registro que era intrínseca da própria estrutura do dbf.

Já hoje? Só se o custo/benefício compensar muito. Um caso onde o uso vai lhe poupar muitas horas de programação ou trará uma certa confiabilidade no código, geralmente onde a modelagem deixou a desejar.

Eu entendo que não é sempre que dá para fazer tudo perfeito. Às vezes eu tenho que lançar mão de recursos que passam longe de uma boa normalização, rs, mas em casos simples tento manter a fidelidade à norma e poupar recursos.

Ok, ok, eu sei... Às vezes dá uma preguiça...