Problema com mapeamentos + uns erros

Boa tarde !

Bem vindo ao serviço de consultoria da DEVMEDIA.


É necessario que seja aberto um chamado para cada duvidas , assim vou pedir que você selecione qual duvida que deseja ser respondida neste chamado.

Para as outras eu vou pedir que voce abra outros chamados...

Obrigado !

Gostaria de saber como implementar em java estas classes com um exemplo em jsf.

Para ser mais exato e facilitar. Quero saber como  fazer este mapeamento de pessoas,pessoas_fisicas,juridicas,advogado,advogadocontraria em java com um exemplo em jsf. demostrando o cadastro e a recuperacao dos dados.

Eu posso sim colocar aqui varios exemplos...

Porem a DEVMEDIA tem duas SERIES de VIDEO aulas que descrevem EXATAMENTE o que voce esta precisando...

Uma delas se chama "Desvendando o JPA" que vai te ensinar como mapear suas classes , como utilizar HERENCA entre elas e como isso acontece com banco de dados , e a outra serie é a "Desenvolvendo uma Aplicacao Completa Utilizando JPA" que vai abordar justamente a parte de implementacao de classes , como fazer a separacao e como fazer alteracoes e insercoes , tudo isso utilizando JSF...

Sao series completissimas , com uma didatica DIRETA AO ASSUNTO sem enrrolacoes...

Interessa ?

Olá.Eu já tinha visto estas aulas e lhe digo que vc está de parabens.Até achei engraçado sobre os BIG ANIMAIS.Mas o meu problema mesmo não é aquilo. Vamos ver se consigo explicar por aqui e assim vc possa me dar um exemplo.Tenho uma cadastro que tá dando erro. Quando eu cadastro um cliente que é uma classe extendida de Pessoa dá um erro, quando for alterar o cliente funciona.Alguma coisa eu estou fazendo errado.Usando uma classe Static Main como o exemplo do video funciona bz.O problema é na hora de usar a parte visual.E oq eu preciso é uma solucao para fazer mapeamentos entre as classes Pessoas,pessoasFisicas,pessoasJuridicas,Clientes por exemplo -Quando gravar em Clientes, o toplink vai ter que gravar em Pessoas e DEPENDENDO gravar ou em pessoa fisica ou em pessoa juridica nas minhas tabelas.O problema se encontra por ae.Preciso de um exemplo ae q vc possa fazer para que possa seguir em diante. 

Estarei analisando e amanha posto o codigo !

OK ?

ok.fico no aguardo.qualquer duvida sobre o problema.Me pergunte.evitando assin desentendimentos

Ola Dyego.Estou com um pouco de urgencia..Poderia me informar como está o procedimento?

Dando uma olhada melhor na sua duvida eu acabei fazendo um exemplo de heranca , porem acredito que nao eh isso certo ? Qual é o erro que está apresentando ?

Voce poderia postar o STACKTRACE completo ?

Ola Dygo.Em relação ao erro já foi resolvido.Mas  a principal duvida neste chamado é uma solução para oque foi descrito.Não sei se o uso de herança seria a melhor escolha no meu caso.Geralmente a composição costuma ser a melhor forma e tem benefícios excelente.
Mas indo direto no assunto. O que eu preciso é um exemplo com as seguintes classes. Mapeamento com estas classes(Pessoas,PessoasFisicas,PessoasJuridicas,Clientes.)
Fazer o mapeamento com Pessoas e Clientes é muito fácil e já funcionava tranquilo.O problema é quando for fazer o mapeamento com pessoa Fisica e Pessoa juridica.Não basta apenas fazer um mapeamento simples, pois eu preciso de alguma coisa que meu JPA entenda que ou grava em pessoa fisica ou grava em pessoa juridica.Eu tentei usar Discrminate Value,mas nao funciona legal, NO MEU CASO.

Se o discriminator VALUE não funciona no seu caso , podes tentar utilizar a ESTRATEGIA denonima JOINED , voce já tentou utiliza-la ?

Olá Dygo.Já tentei todas as classes estão utilizando joined.Mas como informado.O ruim do Joined e de extender para pessoa é que o JPA faz um insert neles e não é isto que eu quero.

Explicando....

QUando cadastro um cliente, o meu JPA deve fazer um insert  em Cliente, depois em Pessoas e depois OU em pessoas Fisicas ou em Pessoas Juridicas.

O ideal seria fazer um joined entre clientes e um discrimator value com pessoas juridicas e fisicas

Porem o jpa nao permite isto(Ou é joined ou é discrimantor..PELO MENOS NAO CONSEGUI ISTO>AH NA SER QUE EXISTA UM MODO DE FAZER E FIZ ERRADO).Porq se permitisse ja seria resolvido.Pois faria um insert em clientes, o jpa faria em pessoas e dependendo do check box se fosse fisica O DISCRIMATOR VALUE = FISICA faria insert em pessoa fisica e se o DISCRIMATOR VALUE = JURIDICA faria insert em pessoa Juridica.

O JPA suporta apenas UMA estrategia... ou vc trabalha com JOINED ou com SINGLETABLE...

Em todo a minha experiencia como desenvolvedor eu nunca precisei quebrar tanto assim as tabelas... tem certeza que eh a melhor abordagem ? Crie uma tabela PESSOA e herde para PESSOA FISICA ou JURIDICA...

E crie um campo para indicar se é um cliente ou não... resolveria o seu caso ?:

ps: muita heranca em ORM só dá zica... evite ao maximo.

O JPA suporta apenas UMA estrategia... ou vc trabalha com JOINED ou com SINGLETABLE...

Em todo a minha experiencia como desenvolvedor eu nunca precisei quebrar tanto assim as tabelas... tem certeza que eh a melhor abordagem ? Crie uma tabela PESSOA e herde para PESSOA FISICA ou JURIDICA...

E crie um campo para indicar se é um cliente ou não... resolveria o seu caso ?:

ps: muita heranca em ORM só dá zica... evite ao maximo.

-------------------------------------------------------------

Então.Se fosse fazer desta forma já estaria feito.Porem nao funcionaria(Digo que funcionaria sim,mas seria como se fosse um tabelão).Pensa comigo...Dados dos funcionarios são diferentes dos clientes, dados dos advogados diferencias com estes também

A relação usada é

Clientes extends Pessoas
clientesContrarios extends Clientes
Funcionarios extends pessoas
Advogados extends pessoas
AdvogadosAdversos extends advogados
Usuarios extends Pessoas

Bom..Se não tiver nenhum sugestão para este caso, eu posso mudar de assunto neste CHAMADO.Fico no aguardo

Deixa eu ver se entendi...

Todos os outros mapeamentos funcionam , porem o :

clientesContrarios extends Clientes

Que está dando problema certo ?

VIXI.kakaka.Ta dificil.:>

Vamos lá..Tentar explicar novamente

Preciso de um exemplo, ou seja uma solução...

Imagina assim,Vamos imaginar que estou cadastrando um Cliente Adverso.
O JPA vai dar um INSERT em Cliente Adverso, depois em Cliente, depois em Pessoas..
Aeeeeeeeee, por alguma regra(DE MAPEAMENTO) ele vai dar ou insert em Pessoas Fisicas ou em Pessoas Juridicas

Do mesmo modo que chamar os dados na tabela ele precisa chamar clientes adversos,clientes,pessoas eeeeee
OUUU pessoas fisicas ou pessoas juridicas..

Para facilitar..Como vc faria isto?dependendo de como vc fizer..Já ajude..Mas oq preciso mesmo é esta solução Ou algo parecido.Ë isto que ta quebrando minha cabeça.E a apresentação é sábado de manha.E por isto até quinta no máximo preciso estar colocando isto no programa.

Olá Andrei,

acompanhei o seu post desde o início e, pelo que pude entender, sua dúvida diz respeito às estratégias que podem ser utilizadas no mapeamento de herança em JPA, correto?

Como nesta thread não há informações específicas o suficiente sobre a sua aplicação ainda, acho melhor começarmos com alguma teoria a respeito. Sendo assim, recomendo que você dê uma lida neste link:
http://java.sun.com/javaee/5/docs/tutorial/doc/bnbqa.html#bnbqn

Trata-se da documentação oficial da Sun a respeito da implementação atual d JPA (JEE 5.0), aonde são definidas as três únicas políticas de mapeamento de herança:

* single table (quando em uma única tabela são armazenadas todas as informações relativas a todas as classes filhas) e

* uma tabela por classe concreta

* estratégia de "join".

No seu caso, pelo que pude comrpeender, o problema diz respeito à pessoas físicas ou jurídicas. Acredito que a terceira alternativa seja mais viável. Nesta alternativa, as informações comuns aos dois tipos de pessoa encontram-se armazenadas em uma única tabela, e os dados específicos de cada tipo em tabelas separadas.

No site da Caelum há um post muito interessante sobre o assunto, que também recomendo que você dê uma lida:
http://blog.caelum.com.br/2007/03/04/jpa-com-hibernate-heranca-e-mapeamentos/
(curiosamente, o exemplo apresentado é exatamente o seu)

Eu já tinha visto este dois links antes, e não encontrei oque procurava neles.

Entao..Vamos lá.Vamos IMAGINAR que o JPA permita ESTE CODIGO.Se permitisse eu tava feliz da vida..MAS ELE NAO PERMITE.

imagina assim.....

public class Pessoa implements Serializable{
@Entity
@Table(name = "pessoas")
@Inheritance (strategy=InheritanceType.JOINED) //será usado para papeis de pessoas(clientes,funcionarios,advogados,entre outros)
@DiscriminatorColumn(name= "Tipo",discriminatorType=DiscriminatorType.STRING//sera usado para pessoa fisica,juridica
}


-----------------------------------
@Entity
@Table(name = "clientes")
@PrimaryKeyJoinColumn(name = "idPessoas")
public class Clientes extends Pessoas implements Serializable {
}
-------------------------------------
@Entity
@Table(name = "advogados")
@PrimaryKeyJoinColumn(name = "idPessoas")
public class Advogados extends Pessoas implements Serializable {
--------------------------------------
@Entity
@Table(name = "pessoas_fisicas")
@DiscriminatorColumn(name="PessoaFisica")
public class PessoasFisicas extends Pessoas implements Serializable {
--------------------------------------
@Entity
@Table(name = "pessoas_juridicas")
@DiscriminatorColumn(name="PessoaJuridica")
public class PessoasJuridicadas extends Pessoas implements Serializable {

COMO FUNCIONARIA?

ACHO QUE VC ATÉ PERCEBEU..MAS NA DUVIDA...EXPLICANDO

IMAGINA AGORA QUE ESTOU INSERINDO ALGO EM CLIENTES...ASSIMMM
O nosso querido JPA faria um insert em Clientes,depois em Pessoas usando a anotação joined e ae ele verificaria em pessoas o @DiscriminatorColumn e se for passado TIPO FISICA ele da insert na tabela fisica , ou se for passado TIPO Juridica ele da insert na tabela Juridica..

Veja que lindo ia ser se ele  fizesse isto com esta junção de anotações.eu tentei fazer isto mas não é possivel fazer..Bom..Se isto ainda existe...Eu não sei te afirmar.Foi a melhor forma que pude chegar.Foi na tentativa fazer isto, mas por meu azar,Não funcionou...

Vamos fazer assim...Como estou na urgencia de fazer,se não tiver outra maneira de se resolver, ao invez de resolver isto eu mudarei de assunto para outro erro que tenho, por ser um erro acho que seria mais facil de resolver. Mas muito obrigado por tentar ajudar.E como vc ganha por topicos resolvidos,eu ja libero este topico ao resolver o erro e ae deixamos este topico mais para frente...

Andrei,

vamos analisar o seu código ok?

@Entity
@Table(name = "pessoas")
@Inheritance (strategy=InheritanceType.JOINED) //será usado para papeis de pessoas(clientes,funcionarios,advogados,entre outros)
@DiscriminatorColumn(name= "Tipo",discriminatorType=DiscriminatorType.STRING//sera usado para pessoa fisica,juridica
}

Se a sua estratégia é do tipo InheritanceType.JOINED, o discriminador é desnecessário, uma vez que o ORM irá identificar o tipo da classe a partir das demais tabelas.

-----------------------------------
@Entity
@Table(name = "clientes")
@PrimaryKeyJoinColumn(name = "idPessoas")
public class Clientes extends Pessoas implements Serializable {
}
-------------------------------------
@Entity
@Table(name = "advogados")
@PrimaryKeyJoinColumn(name = "idPessoas")
public class Advogados extends Pessoas implements Serializable {
--------------------------------------
@Entity
@Table(name = "pessoas_fisicas")
@DiscriminatorColumn(name="PessoaFisica")
public class PessoasFisicas extends Pessoas implements Serializable {

Novamente, aqui você não precisa de um discriminator. Afinal de contas, todas as pessoas físicas estão armazenadas na mesma tabela "pessoas_fisicas"

--------------------------------------
@Entity
@Table(name = "pessoas_juridicas")
@DiscriminatorColumn(name="PessoaJuridica")
public class PessoasJuridicadas extends Pessoas implements Serializable {






Vamos então aqui dar uma discutida nesta estratégia ok? A idéia é simples: em uma tabela central, você incluiria os campos que são comuns a todas as classes filhas, ou seja, os atributos que se encontram na classe pai.

O ORM irá identificar os tipos das classes filhas a partir das tabelas aonde as mesmas estão armazenadas. Sendo assim, seguindo o seu exemplo, o ORM já saberia de antemão que, se você está buscando registros do tipo PessoasFisicas, estará buscando estas informações na junção da tabela "pessoas" com a tabela "pessoas_fisicas".

Como a identificação do tipo é feita a partir das tabelas, não é necessário um campo discriminador. Se por exemplo você pedisse para listar todas as pessoas independente do tipo, o que o ORM faria por trás dos panos consistiria na execução de uma consulta do tipo UNION, na qual cada subconsulta representaria um tipo específico de pessoa.

Agora, vamos pensar em como seria a atualização dos dados. Supondo que estamos trabalhando com uma instância da classe PessoasFisicas, o que o ORM faria consistiria em atualizar os registros relativos presentes tanto na tabela "pessoas" quanto na tabela "pessoas_fisicas".

A pergunta que fica aqui agora portanto seria: "como o ORM sabe como fazer a junção? ". Simples, obrigando o programador a incluir a anotação @PrimaryKeyJoinColumn nas classes derivadas.

Isto responde à sua dúvida?

Ola Henrique..Estamos chegando lá.É quase isto mesmo.Sobre o funcionamento.Já estou informado dos tipos e das funcionalidades.Mas é por ae mesmo..Segue ae as tabelas do meu banco.Teria como descrever sobre oq vc falou antes..colocando um exemplo?pode ser por aqui mesmo,escrito...lembrando que pessoas tem tipos e papeis.

Apenas incrementando umas perguntas pelo que vc disse.

Se eu mapear todas estas tabelas Pessoas,PessoasFisicas,PessoasJuridicas,Clientes,Advogados usando JOIN

Quando eu der um insert em Clientes.O programa irá insertir dados na tabela clientes,pessoas,pessoasfisicas e pessoas juridicas?

SE SIM É AE QUE TA O PROBLEMA

é ae que ta minha duvida....e é ae que quase estamos chegando...

Eu preciso de algo que quando na minha pagina JSP de cadastro de clientes, quando escolher TIPO Pessoas Fisica, o meu jpa faça um insert na tabela clientes,pessoas e pessoas FISICAS APENAS. E JAMAIS NAS DUAS.

E quando for consultar um cliente, ele deve fazer join em pessoas eeeeeeeeeeeee DEPENDENDO OU EM PESSOAS FISICAS OU EM PESSOAS JURIDICAS.... E NAO UM UNION EM PESSOAS FISICAS E JURIDICAS.....


COMO INFORMADO AQUELE CODIGO NAO FUNCIONA  E SEI QUE QUANDO SE USA JOIN, NAO HA NECESSIDADE de usar @Inheritance (strategy=InheritanceType.JOINED).
Aquele codigo apenas foi feito que todas classes contendo discrimator ira basear nisto e aquelas que nao tiver ira basear no join.


bom..Como vc faria esta relação então?Talvez esteja falando de algo que ainda não invetaram.

Oi Andrei,

bom: seu problema então pode ser solucionado da seguinte forma: na sua interface gráfica, seja ela web, desktop, móvel, etc, você deve aplicar portanto o padrão factory.

Este padrão irá instanciar para você o tipo desejado com o qual você deseja trabalhar. Se for por exemplo uma pessoa jurídica, ele irá criar uma nova instância para você, de acordo com esta lógica. Neste caso, portanto, tudo o que você precisa fazer consiste em popular os devidos atributos desta sua instância e, em seguida, persistir os dados desta classe usando o JPA.

No entanto, convém mencionar novamente aqui o que irá acontecer ok? Se for por exemplo uma instância de PessoaJuridica, de acordo com o seu modelo, serão persistidos os campos presentes na tabela Pessoas (que está mapeada para a super classe de PessoaJuridica) e também os dados presentes na tabela Pessoas_Juridicas, visto que os dados da sua instancia de PessoaJuridica encontram-se distribuidos nestas duas tabelas.

A persistência se dá nestas duas tabelas porque se assim não o fosse, não faria sentido utilizar a estratégia JOIN, concorda? Isto pode ser provado da seguinte forma:

suponha que eu salvasse os dados apenas na tabela Pessoas. Se nada fosse persistido em nenhuma das outras tabelas, como identificar aquele registro como sendo do tipo PessoaJuridica ou PessoaFisica?

agora, supondo que eu só persistisse os dados na tabela Pessoa_Juridica. Como identificar o nome da Pessoa?

Isto explica o porquê, neste caso (usando a estratégia join), necessáriamente estas duas tabelas (e apenas estas duas) precisam ser preenchidas.

Agora, vamos passar para a estratégia adequada para que você possa persistir apenas os dados do tipo de pessoa que você deseja. Como mencionei anteriormente, uma solução consiste na utilização do padrão factory. Este padrão visa apenas criar novas instâncias das suas classes. Sendo assim, poderia ser criado um factory bem bobo, como por exemplo o abaixo:

public class FactoryPessoa {
    public Pessoa instanciarPessoa(String nome) {
        if (nome.equals("juridica")) {
             return new PessoaJuridica();
        }
        if (nome.equals("fisica")) {
              return new PessoaFisica();
        }
        // e por ai vai.
    }
}

O Factory acima é bem tosco. Mas é só para dar uma idéia do funcionamento do padrão. No caso, ele saberia qual instancia criar a partir da string que você passasse (outra alternativa mais elegante poderia ser um factory que recebesse como parametro um objeto do tipo java.lang.Class (fica como exercicio para voce ok?))

Bom: com base neste factory, a sequencia de execução seria basicamente a seguinte:

* Crie uma nova instancia usando o factory com o tipo que voce deseje
* Preencha os atributos desta nova instancia de acordo com a sua vontade
* Persista com o JPA (ele saberá quais tabelas utilizar com base no mapeamento que voce tenha feito).

Agora, claro que no caso da sua interface gráfica, ela deverá ser customizada para cada tipo. Neste caso, o seu controlador poderia inclusive já fazer o redirecionamento para o formulário adequado de acordo com o tipo de pessoa que você estiver trabalhando.

Com relação à consulta. A solução também é simples. Utilizando a lingaugem de consulta do JPA (a JPQL. vide link http://java.sun.com/javaee/5/docs/tutorial/doc/bnbtg.html), voce pode estipular qual o tipo de classe que deseja listar. Sendo assim, se fosse para listar, por exemplo, apenas as pessoas jurídicas, poderia por exemplo escrever uma consulta como a abaixo, retornando apenas as pessoas jurídicas:

from seupacote.PessoaJuridicas p

Ola.Olhando atentamente é isto mesmo que tinha duvida.Apenas para tirar algumas duvidas que ficaram ao ler seu post.

Se eu precisar mais para frente algo que um cliente possa ser pessoa fisica e pessoa juridica ao mesmo tempo.E se existisse clientes,advogados.O codigo abaixo funcionaria?

public class Pessoa implements Serializable{
@Entity
@Table(name = "pessoas")
@Inheritance (strategy=InheritanceType.JOINED)
para pessoa fisica,juridica
}
-----------------------------------
@Entity
@Table(name = "clientes")
@PrimaryKeyJoinColumn(name = "idPessoas")
public class Clientes extends Pessoas implements Serializable {
}
-------------------------------------
@Entity
@Table(name = "advogados")
@PrimaryKeyJoinColumn(name = "idPessoas")
public class Advogados extends Pessoas implements Serializable {
--------------------------------------
@Entity
@Table(name = "pessoas_fisicas")
@PrimaryKeyJoinColumn(name = "idPessoas")
public class PessoasFisicas extends Pessoas implements Serializable {
--------------------------------------
@Entity
@Table(name = "pessoas_juridicas")
@PrimaryKeyJoinColumn(name = "idPessoas")
public class PessoasJuridicadas extends Pessoas implements Serializable {
-------------------------------------------------------------------------------------------------------------------------------------
Vc me passou um link de consulta de query.Quer dizer que se eu fazer uma query para buscar pessoas,clientes e apenas pessoas fisicas e teria que fazer um join nelas para trazer em uma data table?
------------------------------------------
Se eu usasse esta funcao quer dizer que as classes pessoas fisicas e pessoas juridicas nao tera mais @PrimaryKeyJoinColumn(name = "idPessoas") ?
public class FactoryPessoa {
    public Pessoa instanciarPessoa(String nome) {
        if (nome.equals("juridica")) {
             return new PessoaJuridica();
        }
        if (nome.equals("fisica")) {
              return new PessoaFisica();
        }
        // e por ai vai.
    }
}
--------------------------------------------------------------------------------------------------------------------------------------
E para finalizar o topico...Vc que é um profissional como vc faria?
Os dados das pessoas juridicas,fisicas,vc colocaria separado?


FIM>OBRIGADO PELA AJUDA>Aguardo apena estas duvidas referente ao topicos da conversa.Para finalizar este topico eu escolho a opcao "Exatamente Resolvida?"

E continuando..Nao entendi aqui
---
Agora, claro que no caso da sua interface gráfica, ela deverá ser customizada para cada tipo. Neste caso, o seu controlador poderia inclusive já fazer o redirecionamento para o formulário adequado de acordo com o tipo de pessoa que você estiver trabalhando.

Oi Andrei,

bom: vamos então de cima pra baixo agora ok?

Primeiro com o que você não entendeu:

E continuando..Nao entendi aqui
---
Agora, claro que no caso da sua interface gráfica, ela deverá ser customizada para cada tipo. Neste caso, o seu controlador poderia inclusive já fazer o redirecionamento para o formulário adequado de acordo com o tipo de pessoa que você estiver trabalhando.

Estava me referindo aqui ao fato de haverem campos que não deveriam ser expostos para determinados tipos de pessoa: por exemplo: a pessoa física não deve preencher o campo cnpj. Sendo assim, na sua aplicação jsf, você teria de trabalhar com este fato, seja redirecionando o usuário para uma página específica para aquele tipo ou mesmo definindo quais campos apresentar na tela.

Agora, com relação ao seu post anterior:

Vc me passou um link de consulta de query.Quer dizer que se eu fazer uma query para buscar pessoas,clientes e apenas pessoas fisicas e teria que fazer um join nelas para trazer em uma data table?

Na realidade não Andrei. A partir do momento em que você está passando a responsabilidade de acessar e escrever dados no SGBD ao ORM, este é trabalho dele, e não seu. Sendo assim, é de responsabilidade deste componente fazer as consultas no banco de dados. No caso, o trbalho do desenvolvedor consiste em apenas fazer os mapeamentos.

Se eu usasse esta funcao quer dizer que as classes pessoas fisicas e pessoas juridicas nao tera mais @PrimaryKeyJoinColumn(name = "idPessoas") ?

Opa, não não. Aqui o que acontece é o seguinte: as anotações já estão na declaração das classes que você fez. Tudo o que este método faz é criar novas instâncias das mesmas, todas filhas da superclasse Pessoas para você. Sendo assim, não é feita qualquer alteração na estrutura das classes aqui neste caso.

Se eu precisar mais para frente algo que um cliente possa ser pessoa fisica e pessoa juridica ao mesmo tempo.E se existisse clientes,advogados.O codigo abaixo funcionaria?

O código abaixo funciona sim, no entanto, pela herança, uma pessoa (pelo seu código) só pode ser de um tipo: Fisica, Juridica ou Advogado. No caso, se você quisesse que uma pessoa fosse física e jurídica ao mesmo tempo, teria de criar um novo subtipo baseado na classe Pessoa.

E para finalizar o topico...Vc que é um profissional como vc faria?
Os dados das pessoas juridicas,fisicas,vc colocaria separado?

É uma boa pergunta Andrei. As duas possibilidades tem suas vantagens e desvantagens. Sendo assim, vamos lá:

* Tudo em uma mesma tabela
Vantagem: é mais fácil fazer consultas para um determinado tipo
(select * from where discriminador = _valor_que_discrimina_aquele_tipo_). Sendo assim, em tese, a performance seria superior pois você não teria de fazer joins.

Desvantagem: e se dois tipos no futuro apresentarem propriedades diferentes porém mapeadas para o mesmo campo?
Outra desvantagem: muitos campos em uma tabela implica em maior complexidade mental para quem for dar manutenção nos dados.
E outra: talvez o ganho de perforamnce teórico que mencionei acima se perca devido ao tamanho da tabela.

* Dados específicos em tabelas específicas
* Vantagem: sua tabela principal irá ficar significativamente menor e seus banco de dados melhor normalizado
* Desvantagem: você precisará de joins para identificar tipos diferenciados e não saberá de antemão se um registro na tabela pai é de um tipo ou outro sem fazer o join

No final das contas Andrei, é uma questão de situação mesmo. Cada situação possui seus requisitos. Não há uma opção que seja melhor ou pior para todos os casos.

Para finalizar este topico eu escolho a opcao "Exatamente Resolvida?"
Uai Andrei, você seleciona resolvida se de fato conseguimos resolver as suas dúvidas. Não sei quais são as opções que aparecem para você pois eu só respondo os chamados.

Qualquer coisa, estamos a sua disposição

Bom.Agora ficando uma pergunta


Sobre a pergunta e resposta abaixo...No meu caso como seria então o mapeamento ,que  uma pessoa poderia ser CLiente ou Advogado ou Funcionario e pessoa fisica ou juridica.
talvez vc ja tenha me dito mas fiquei meio confuso
<---
Se eu precisar mais para frente algo que um cliente possa ser pessoa fisica e pessoa juridica ao mesmo tempo.E se existisse clientes,advogados.O codigo abaixo funcionaria?

O código abaixo funciona sim, no entanto, pela herança, uma pessoa (pelo seu código) só pode ser de um tipo: Fisica, Juridica ou Advogado. No caso, se você quisesse que uma pessoa fosse física e jurídica ao mesmo tempo, teria de criar um novo subtipo baseado na classe Pessoa.
-->


só para exemplificar :

ADvogado1 é pessoa fisica
Advogado2 é pessoa fisica
advogado3 é pessoa juridica
cliente 1 é pessoa fisica

e assim por diante.. A  relação que eu fiz no mapeamento já funciona com isto mesmo?Ou teria que mudar algo?
Bom...é isto ae...olhando atentamento só fica esta duvida e finalizamos aqui.Abraços.E até outro chamados.

Andrei,

neste caso, acredito que se trate mais de um problema de modelagem do que de mapeamento na base de dados.

É importante salientar que uma ferramenta ORM normalmente atende uns 90% dos casos. No entanto, há situações nas quais a coisa já se complica um pouco mais.

Imaginemos, no seu exemplo, um registro de pessoa que seja ao mesmo tempo cliente e advogado ok?

Como seria, ignorando o mapeamento objeto-relacional, mas sim a própria classe em si? Lembre-se: o mapeamento objeto relacional só popula os atributos das suas classes, ela não cria novos tipos.

No entanto, se uma pessoa for do tipo advogado e ao mesmo tempo cliente ou pessoa jurídica, não é de mapeamento que estamos falando. É de modelagem das suas próprias classes. No design das mesmas, você deveria implementá-las de tal modo que permitisse esta possibilidade. Tal como estão atualmente, isto não é possível (um registro ou é pessoa jurídica ou é advogado, mas nunca o mesmo, tal como se encontra agora).

Nesta nova abordagem, talvez nem sequer tipos diferentes de pessoas distintas você teria. Talvez houvesse apenas uma única classe, com um atributo que identificasse os tipos daquela pessoa (poderia ser usado por exemplo um operador or sobre inteiros para permitir isto) e todos os atributos de todos os tipos das pessoas armazenados na mesma tabela. Uma solução tosca, é verdade, mas solucionaria o seu problema.

Outra solução para o seu problema poderia consistir em ter uma tabela Pessoa e outras n tabelas, cada uma das quais identificando um tipo diferente, muito similar ao que você tem agora. A diferença é que se houvesse um relacionamento entre uma destas tabelas e a tabela pessoa, indicaria que aquele individuo possui mais de uma característica. Nesta situação, portanto, herança não seria adequada, pois estas tabelas que mencionei seriam atributos da sua pessoa que a identificassem como sendo de determinado tipo, e não tipos diferentes de pessoa, tal como temos feito até agora.

Outra solução para o seu problema poderia consistir em ter uma tabela Pessoa e outras n tabelas, cada uma das quais identificando um tipo diferente, muito similar ao que você tem agora. A diferença é que se houvesse um relacionamento entre uma destas tabelas e a tabela pessoa, indicaria que aquele individuo possui mais de uma característica. Nesta situação, portanto, herança não seria adequada, pois estas tabelas que mencionei seriam atributos da sua pessoa que a identificassem como sendo de determinado tipo, e não tipos diferentes de pessoa, tal como temos feito até agora.

Levando em consideração então a modelagem feita , quer dizer que uma pessoa poderia ser advogado,advogadocontraria,clientes,pessoa juridica e fisica tudo ao mesmo tempo?
Poderia explicar assim
ex:A sua modelagem de dados diz que um advogado pode ser pessoa,pessoajuridica,pessoafisica,cliente ao mesmo tempo e blablabla
Acho que entenderei assim melhor..

Mas é isto mesmo..estou sastifeito...


-----------------------------------------------------------------------------
Eu gostaria de saber se outro meu chamado poderia ser atendido por vc.Pois vejo que voce consegue entender mais rapidamente minhas duvidas.Nada pessoa contra a capacidade do outro profissional.Mas acho que o nosso entendimento está melhor...Se sim,peço que veja o meu video no you tube da duvida para que facilite ainda mais

Assim se puder trocar,nos vemos no outro chamado.Neste chamado percebi que oq eu tinha em mente,algumas coisas estavam errada e por isto estou tirando as possiveis duvidas.Porque na hora que vem a pratica surge tantas duvidas que dá dor de cabeça.

Levando em conta a modelagem feita você teria um problemão se uma pessoa pudesse ter mais de um tipo, pois a ferramenta ORM não saberia identificar qual o tipo que deveria instanciar para você ao buscar dados na base de dados.

Alguns problemas poderiam ocorrer:

* Uma excessão poderia ser disparada

* Mais de uma instância, uma de cada tipo poderia ser retornada. Suponhamos, por exemplo, um registro no BD que seja pessoa física E jurídica. Ele te retornaria duas instancias, uma do tipo PessoaFisica e outra do tipo PessoaJuridica, ambas apresentando a mesma chave primária.

Uai Andrei,

obrigado pela preferência. No caso, basta que você converse com o pessoal da moderação ok?

Um abraço

Entao na minha modelagem.
Um cliente é cliente
um advogado é advogado
e uma pessoa fisica é pessoa fisica
e jamais advogado e pessoa fisica juntos.
e jamais clientes e advogados juntos
e jamais clientes e pessoa juridica e fisica juntos certo?

Por favor como que coloco este topico como resolvido?
aqui aparece uma mensagem para finalizar mas da erro

Por favor, preencha os dados de feedback corretamente Equipe de moderação da consultoria:
Precisamos de sua ajuda para manter a qualidade da consultoria DevMedia
Por favor, dê seu feedback sobre a resposta ID#10558:

O consultor está sendo atencioso com você?
Sim, perfeitamente
Nem tanto, poderia ser melhor
Definitivamente não

O consultor está conseguindo/conseguiu resolver seu problema?
Sim, perfeitamente
Mais ou menos
Definitivamente não

Ainda estamos no meio do atendimento, prefiro responder mais a frente.

Eu coloco ae mas nao vaiiiiiii...E como que peço ao moderador para trocar?aonde entro em contato com ele?

Exatamente Andrei.

A sua modelagem atual é exatamente esta.
Se quiser, podemos depois até pensar em alguma alternativa ok?

Eu vou concluir o chamado pra você.

Ola.Como que faço para transferir outro chamado que esta com Dyego para vc?
Sinceramente estou um pouco insastifeito com o atendimento dele e quero fazer todos chamados só com vc.Mas nao encontro nenhum botão e opção para te selecionar..Abraços

Andrei,
o atendimento é feito por sorteio, ou seja, nem sempre os seus chamados vão cair para o Henrique. Os mesmos só poderão ser redirecionados se o consultor por ventura não conseguir resolver o seu problema.
Foi postado uma mensagem no outro chamado sobre seu problema.