Modelagem de um Cadastro de Clientes

ao invés de criar duas tabelas, uma para pessoa física (com CPF e identidade) e outra para pessoa jurídica (com CNPJ e insc. estadual), é aconselhável utilizar um campo para colocar o CPF e o CNPJ, e um outro para a identidade e insc. estadual juntos?
é uma mal prática de programação? mas compensa?

|alguma contestação?

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+

colocar o CHPj e o CPF em um único campo é algo que um amigo me falou. concordo que é mais prático, mas não sei se estou convencido que ´modelalmente´ é uma boa.
...mas como vc é o cara, e vc ta dizendo...

valeu afarias

|mas não sei se estou convencido que ´modelalmente´ é uma boa.
|...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+

Pra falar a verdade eu sempre uso várias tabelas para tratar de pessoas.

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]

é exatamente assim que estou usando, mais estou tendo problemas para formatar o campo... se alguem puder me ajudar...

eu utilizo um campo chamado Tipo_Pessoa (Char 1), onde digo se:
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.

Eu também separo endereços e fones.

Com relação ao CPF e CNPJ, uso um único campo, e defino se é um ou outro pelo tamanho (14 ou 11 digitos)

Bem... acho q o domínio onde a aplicação está inserido é fundamental para tomada de decisão a esse respeito!

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

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.

vejo o CPF/CNPJ  como um campo único , identificador númerico da pessoa seja PJ ou PF.