Ir ao conteúdo
  • Cadastre-se
Foxanger

Normalizacao de banco de dados

Recommended Posts

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:

post-780382-13884966664014_thumb.jpg

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?

Compartilhar este post


Link para o post
Compartilhar em outros sites

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.

  • Curtir 1

Compartilhar este post


Link para o post
Compartilhar em outros sites

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.

Compartilhar este post


Link para o post
Compartilhar em outros sites

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

Compartilhar este post


Link para o post
Compartilhar em outros sites

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.

Compartilhar este post


Link para o post
Compartilhar em outros sites

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

Compartilhar este post


Link para o post
Compartilhar em outros sites

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... :D

Compartilhar este post


Link para o post
Compartilhar em outros sites

É que alguns sistemas são melhorias dos dbase e Clipper de mil novecentos e bolinha, por isso ainda existe essa "preguiça" no código, hehehe.

Mas é claro que nos módulos e sistemas atuais não, ou pelo menos "não são necessários".

E o Foxanger, o que resolveu? ^^

Compartilhar este post


Link para o post
Compartilhar em outros sites

Taí uma verdade, rs. As melhorias de sistemas antigos que ainda "botam prá quebrar". Daí vê-se que o negócio, no mínimo, era bom mesmo, rs.

Já o Foxanger deve ter arrésorvido por lá ou ficou na moita... rsrsrs!

Compartilhar este post


Link para o post
Compartilhar em outros sites

Crie uma conta ou entre para comentar

Você precisar ser um membro para fazer um comentário

Criar uma conta

Crie uma nova conta em nossa comunidade. É fácil!

Crie uma nova conta

Entrar

Já tem uma conta? Faça o login.

Entrar agora





Sobre o Clube do Hardware

No ar desde 1996, o Clube do Hardware é uma das maiores, mais antigas e mais respeitadas publicações sobre tecnologia do Brasil. Leia mais

Direitos autorais

Não permitimos a cópia ou reprodução do conteúdo do nosso site, fórum, newsletters e redes sociais, mesmo citando-se a fonte. Leia mais

×