logo DevMedia  
Home Entenda o site Revistas Canais Cursos Palestras Suporte Fórum +Serviços Assine Compre Créditos

Edição do Mês
  Fórum DevMedia
Fórum de Discussão
Conheça também o NOVO fórum da DevMedia, no endereço: www.devmedia.com.br/forum
O novo fórum possui diversas vantagens! Saiba mais em
www.devmedia.com.br/articles/viewcomp.asp?comp=14726
Estamos sempre trabalhando na melhora do site como um todo! Bons códigos!
Equipe DevMedia

 FAQFAQ   PesquisarPesquisar   MembrosMembros   GruposGrupos  RegistrarRegistrar   
 PerfilPerfil   Entrar e ver Mensagens ParticularesEntrar e ver Mensagens Particulares   EntrarEntrar 
Edição do Mês

Modelagem de um Cadastro de Clientes
 
Novo Tópico   Responder Mensagem    Fórum DevMedia - Índice do Fórum -> Modelagem de Dados
Exibir mensagem anterior :: Exibir próxima mensagem  
Autor Mensagem
raserafim
Membro Senior


Registrado em: Quinta-Feira, 9 de Outubro de 2003
Mensagens: 1071
Localiza?: Natal-RN

MensagemEnviada: Sex Dez 30, 2005 12:19 am    Assunto: Modelagem de um Cadastro de Clientes Responder com Citação

pode parecer bem simples, mas queria aqui levantar um detalhe da modelagem, que vejo sempre passar desapercebido.
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?
Voltar ao Topo
Ver o perfil de Usuários Enviar Mensagem Particular
raserafim
Membro Senior


Registrado em: Quinta-Feira, 9 de Outubro de 2003
Mensagens: 1071
Localiza?: Natal-RN

MensagemEnviada: Qui Jan 05, 2006 12:29 am    Assunto: Responder com Citação

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?
Voltar ao Topo
Ver o perfil de Usuários Enviar Mensagem Particular
afarias
Membro Senior


Registrado em: Domingo, 6 de Abril de 2003
Mensagens: 5374
Localiza?: Recife, PE

MensagemEnviada: Qui Jan 05, 2006 11:48 am    Assunto: Responder com Citação

|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+
_________________
SUPORTE, A SÉRIE:
http://andre.openintelligence.com.br/


*** Assessoria em Delphi (Win32) e Firebird ***
Resolução de problemas, orientação técnica, programação de ferramentas ou módulos, e mais!
Entre em contato!
Voltar ao Topo
Ver o perfil de Usuários Enviar Mensagem Particular
raserafim
Membro Senior


Registrado em: Quinta-Feira, 9 de Outubro de 2003
Mensagens: 1071
Localiza?: Natal-RN

MensagemEnviada: Sex Jan 06, 2006 3:44 am    Assunto: Responder com Citação

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
Voltar ao Topo
Ver o perfil de Usuários Enviar Mensagem Particular
afarias
Membro Senior


Registrado em: Domingo, 6 de Abril de 2003
Mensagens: 5374
Localiza?: Recife, PE

MensagemEnviada: Sex Jan 06, 2006 2:07 pm    Assunto: Responder com Citação

|mas não sei se estou convencido que "modelalmente" é uma boa.
|...mas como vc é o cara, e vc ta dizendo

hahahahahahahahahaha... Razz Razz Razz

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 Smile

Não tente se convencer se é certo ou não. Tome como 1 experiência e avalie se á válida para vc! Wink


T+
_________________
SUPORTE, A SÉRIE:
http://andre.openintelligence.com.br/


*** Assessoria em Delphi (Win32) e Firebird ***
Resolução de problemas, orientação técnica, programação de ferramentas ou módulos, e mais!
Entre em contato!
Voltar ao Topo
Ver o perfil de Usuários Enviar Mensagem Particular
ladamiak
Novato


Registrado em: Terça-Feira, 7 de Fevereiro de 2006
Mensagens: 2

MensagemEnviada: Ter Fev 07, 2006 8:19 pm    Assunto: Concordo Responder com Citação

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
http://www.megavenda.com
Voltar ao Topo
Ver o perfil de Usuários Enviar Mensagem Particular
brunoagbr
Novato


Registrado em: Quarta-Feira, 15 de Fevereiro de 2006
Mensagens: 38

MensagemEnviada: Dom Fev 19, 2006 8:07 pm    Assunto: Responder com Citação

raserafim escreveu:
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?


é exatamente assim que estou usando, mais estou tendo problemas para formatar o campo... se alguem puder me ajudar...
_________________
Bruno Augusto
Voltar ao Topo
Ver o perfil de Usuários Enviar Mensagem Particular Enviar Email
raserafim
Membro Senior


Registrado em: Quinta-Feira, 9 de Outubro de 2003
Mensagens: 1071
Localiza?: Natal-RN

MensagemEnviada: Ter Fev 21, 2006 2:37 pm    Assunto: Responder com Citação

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.
Voltar ao Topo
Ver o perfil de Usuários Enviar Mensagem Particular
Daniel Port
Novato


Registrado em: Quinta-Feira, 8 de Junho de 2006
Mensagens: 8
Localiza?: Novo Hamburgo/RS

MensagemEnviada: Qui Jun 08, 2006 6:03 pm    Assunto: Responder com Citação

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)
Voltar ao Topo
Ver o perfil de Usuários Enviar Mensagem Particular
danilo.dct
Novato


Registrado em: Sexta-Feira, 13 de Março de 2009
Mensagens: 4
Localiza?: Recife - PE

MensagemEnviada: Sex Mar 13, 2009 5:43 pm    Assunto: Responder com Citação

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

Bem... gostaria de discutir aqui com vcs as vantagens e desvantagens de cada abordagem aqui citada.

vlw galera
_________________
Computer Science Graduated Student - CIn/UFPE - 2008
Voltar ao Topo
Ver o perfil de Usuários Enviar Mensagem Particular
Daniel Port
Novato


Registrado em: Quinta-Feira, 8 de Junho de 2006
Mensagens: 8
Localiza?: Novo Hamburgo/RS

MensagemEnviada: Sáb Mar 14, 2009 9:45 am    Assunto: Responder com Citação

danilo.dct escreveu:
Bem... 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".


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.
Voltar ao Topo
Ver o perfil de Usuários Enviar Mensagem Particular
Mostrar os tópicos anteriores:   
Novo Tópico   Responder Mensagem    Fórum DevMedia - Índice do Fórum -> Modelagem de Dados Todos os horários são GMT - 3 Hours
Página 1 de 1

 
Ir para:  
Enviar Mensagens Novas: Proibído.
Responder Tópicos Proibído
Editar Mensagens: Proibído.
Excluir Mensagens: Proibído.
Votar em Enquetes: Proibído.


Powered by phpBB © 2001, 2005 phpBB Group
Traduzido por: Suporte phpBB