Modelagem de um Cadastro de Clientes
30/12/2005
0
o que geralmente vejo é uma tabela para todas as informações do cliente.
mas esta não é uma forma ´bem correta´ de fazer uma base.
o correto seria:
uma tabela para as informações gerais do cliente
outra para endereço
outra para telefones
outra para as informações específicas de pessoa Física
outra com informações específicas de pessoa Jurídica
e outra para observações
alguma contestação?
é realmente necessário usar estas várias tabelas para um único cadastro?
complica muito? o benefício não justifica a complicação?
Como vc´s fazem esta modelagem?
Raserafim
Posts
05/01/2006
Raserafim
é uma mal prática de programação? mas compensa?
05/01/2006
Afarias
quanto a esse seu 1º post eu diria q não há um certo ou errado. já tive experiências com as 2 formas e, na minha opnião, o q vale é escolher o q melhor se adequa a uma necessidade específica.
|é aconselhável utilizar um campo para colocar o CPF e o CNPJ,
|e um outro para a identidade e insc. estadual juntos?
é o q eu faço sempre.
|é uma mal prática de programação?
na minha opnião particular, mal prática é não fazer isso. CPF e CNPJ são o q? Ambos são *inscrições federais* -- só muda o nome -- a mesma coisa para RG e Inscrição Estadual, ambos são *inscrições estaduais*.
Separar essas informações só cria uma complicação q não existe.
T+
06/01/2006
Raserafim
...mas como vc é o cara, e vc ta dizendo...
valeu afarias
06/01/2006
Afarias
|...mas como vc é o cara, e vc ta dizendo
hahahahahahahahahaha... :P :P :P
q isso! Essa é apenas minha visão e experiência. Para mim não existe 1 modelo (o modelo), mas sim um modelo que melhor aborda (melhor custo/benefício) uma determinada situação/necessidade.
Na minha experiência, esse ´modelo´ sempre me serviu como ´o melhor´ em todas as aplicações q tive a oportunidade de criar/participar -- mas isso para os ´requisitos´ que eu tive :)
Não tente se convencer se é certo ou não. Tome como 1 experiência e avalie se á válida para vc! ;-)
T+
07/02/2006
Ladamiak
Geralmente, nos sistemas internos que desenvolvemos uma pessoa pode ser funcionário e cliente, dependendo da situação, (Trabalhamos com sistemas de controle de colaboradores) e nestes casos posso garantir, a complicação vale a pena. A manutenção é muito mais simples.
[]´s
Ladamiak
[url]http://www.megavenda.com[/url]
19/02/2006
Brunoagbr
é exatamente assim que estou usando, mais estou tendo problemas para formatar o campo... se alguem puder me ajudar...
21/02/2006
Raserafim
F = Pessoa Física
J = Pessoa Jurídica
então consigo determinar se é CPF ou CNPJ e com isso definir corretamente qual a máscara utilizar.
08/06/2006
Daniel Port
Com relação ao CPF e CNPJ, uso um único campo, e defino se é um ou outro pelo tamanho (14 ou 11 digitos)
13/03/2009
Danilo.dct
mas a grosso modo unir PF e PJ em uma única classe contendo a UNIAO dos atributos dessas 2 primeiras classes gera uma classe nao coesa. Por outro lado concordo que deixa a ´coisa menos amarrada´.
estou passando por algo parecido... na minha aplicacao tenho a classe Funcionario que extende UserPF e UserPF extende PessoaFisica. Existe tb a classe ClientePF que extende UserPF e ClientePJ que extende UserPJ (User PF extende PessoaFisica e UserPJ extende PessoaJuridica).
Nao gostei muito desta abordagem pq ficamos com dados duplicados em UserPF - UserPJ, e ClientePF - ClientePJ. Uma solucao utopica seria UserPf e UserPJ herdar de User, que teria os dados em comum, mas Java nao nos permite heranca multipla... :(
Bem... gostaria de discutir aqui com vcs as vantagens e desvantagens de cada abordagem aqui citada.
vlw galera
14/03/2009
Daniel Port
Sugiro a quem se interessa pelo assunto, os livros Banco de dados, projeto e implementação, de Felipe Nery Rodrigues Machado e Otimizando a performance de banco de dados, de Roberto Carlos Mayer. Especialmente a página 39, no item ´Quando não normalizar´.
Eu não vejo o CPF/CNPJ como um atributo separado de PF (cpf) e PJ (cnpj), mas sim como um atributo único (inscrição) da pessoa.
Os atributos inerentes a cada tipo de pessoa (PF ou PJ), esses sim estão cada um em sua tabela de especialização.
O grande ´problema´ da especialização muitas vezes é a performance do BD, que fica sacrificada em função do grande número de acessos para recuperação de informações.
Cada caso é um caso, mas muitas vezes é melhor colocar dois campos com telefone, do que colocar em tabelas separadas.
Certa vez peguei um BD em que o cadastro de clientes se desobrava em 35 tabelas diferentes (fones, endereços, ceps, contatos etc.) O BD estava muito bem desenhado, e normalizado, porém ficava lento quando um grande número de atendentes acessava as informações para o telemarketing.
Mas, para o cliente e para o chefe, o fato de BD estar ´perfeitamente´ bem construido, é irrelevante. O relevante é a velocidade do sistema, tanto em inserir, quanto em recuperar informações.
Este é apenas um caso, onde se aprende que na prática, a teoria é diferente.
14/03/2010
Eleuterio Gonzalez
Clique aqui para fazer login e interagir na Comunidade :)
