Como mapear muitos-para-muitos associação a uma classe mapeada para duas tabelas diferentes?

Question

Eu tenho um voucher - POJO mapeado para duas tabelas. Os primeiros cessionários de mapeamento de um nome de entidade "voucherA" e mapeia o POJO para TableA. O segundo mapeamento usos "voucherB" como nome da entidade e mapeia o POJO para TableB.

Agora eu também tenho um cliente POJO mapeado para TableC. Este POJO referências vouchers em uma lista.

<list name="vouchers" table="TableC_vouchers">
  <key column="pid"/>
  <list-index column="position" base="0"/>

  <!-- how to do that right -->
  <many-to-many column="voucher_id" entity-name="voucherB"/>
</list>

Como faço para mapear corretamente uma lista de muitos-para-muitos associações de clientes para comprovantes de modo que se um cliente POJO é mantido, as entidades Vouchers são persistentes para TableB se não existe lá, em vez de TableA? isso pode ser feito? Se não, o que seria uma olhada solução como para que os vales utilizados pelos clientes são persistentes para tableB? (TableA contém apenas Vouchers disponíveis, não os usados)

Answer 1

Seu modelo de núcleo parece errado. Sua entidade Voucher presumivelmente tem muitos atributos - fazer todos eles mudar após ele é usado por um Customer? Eu duvido disso. E, no entanto, você está duplicando-los em seus quadros A e B que significa que seu esquema não é normalizada.

voucher de "Disponível" e "usado" vale não são (ou não deveria ser) a mesma entidade. Eu, em vez de sugerir que você criar uma nova entidade para UsedVoucher que ligaria a ambos Voucher como muitos-para-um e Customer como muitos-para-um e contêm apenas as propriedades "mudou" de Voucher (se houver). Então,

Voucher(id, other attributes) // doesn't change from what you have now
Customer (id, other attributes) // doesn't change except for many-to-many; see below
UsedVoucher(id,
 voucher, // what Voucher was used by that customer
 customer, // what Customer has used that voucher
 changed voucher attributes, // if any
 additional attributes // if needed, such as date/time when voucher was used
)

Seu "many-to-many" na Customer se tornará "um-para-muitos" (coleções de Vouchers utilizados por este cliente) se você precisar dele como propriedade sustentável; caso contrário, é facilmente recuperável através de consulta.

Você pode não fisicamente eliminar da tabela Vouchers neste cenário, embora (a menos que o voucher em questão nunca foi usado). Você vai ter que fazer uma exclusão lógica em seu lugar.

Answer 2

A minha sugestão seria a de armazenar todos os comprovantes na mesma tabela. Para distinguir entre aqueles utilizados e não utilizados você poderia ter um sinalizador booleano ou um valor discriminador (se você estiver usando herança em seu código Java).

Mesmo se você tiver dados existentes que não parece ser a migração seria terrivelmente difícil. Uma vez que todos os comprovantes estão na mesma mesa, a sua relação com os clientes torna-se um straight-forward muitos-para-muitos.

Eu acho que manter duas tabelas seria difícil. Essencialmente, você ainda está armazenando se um voucher é usado ou não, mas você não está fazendo isso de forma explícita. Tenho certeza de que poderia haver uma solução, mas eu acho que o que eu esbocei acima é muito mais simples. Na minha experiência, este é o caminho que escolhi cada vez que quando confrontados com um problema semelhante.