Comment faire correspondre une association plusieurs-à-plusieurs à une classe mappée à deux tables différentes?

Question

J'ai un bon - POJO mappé à deux tables. Le premier mappage attribue un nom d'entité "voucherA" et mappe le POJO à TableA. Le second mappage utilise "voucherB" comme nom d'entité et mappe le POJO à TableB.

Maintenant, j'ai aussi un client POJO mappé à TableC. Ce POJO référence les bons dans une liste.

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

Comment mapper correctement une liste de plusieurs à plusieurs associations de clients à des bons de sorte que si un POJO client est conservé, les entités Voucher sont conservés à TableB s'ils n'y existent pas, à la place de TableA? Cela peut-il être fait? Si ce n'est pas le cas, à quoi ressemblerait une solution de contournement pour que les bons utilisés par les clients soient conservés dans tableB? (La TableA ne contient que les bons disponibles, et non ceux utilisés)

Answer 1

Votre modèle de base semble faux. Votre entité Voucher a vraisemblablement beaucoup d'attributs - est-ce que TOUS changent après qu'il soit utilisé par un Customer? Je doute que. Et pourtant, vous les dupliquez dans vos tables A et B, ce qui signifie que votre schéma n'est pas normalisé.

Le bon «disponible» et le bon «utilisé» ne sont pas (ou ne devraient pas être) la même entité. Je suggérerais plutôt que vous créiez une nouvelle entité pour UsedVoucher qui relierait à la fois Voucher comme plusieurs à un et Customer comme plusieurs-à-un et ne contiendrait que les propriétés «modifiées» de Voucher (le cas échéant). Ainsi,

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 
) 

Votre "many-to-many" sur Customer deviendra "one-to-many" (collections de bons utilisés par ce client) Si vous avez besoin comme propriété maintenable; Sinon, il est facilement récupérable via une requête.

Vous ne pouvez pas supprimer physiquement du tableau Vouchers dans ce scénario (sauf si le bon en question n'a jamais été utilisé). Vous devrez effectuer une suppression logique à la place.

Answer 2

Ma suggestion serait de stocker tous les coupons dans la même table. Pour distinguer les uns des autres et ceux qui ne sont pas utilisés, vous pouvez avoir un drapeau booléen ou une valeur discriminante (si vous utilisez l'héritage dans votre code Java).

Même si vous avez des données existantes, il ne semble pas que la migration serait terriblement difficile. Une fois que tous les coupons sont dans la même table, leur relation avec les clients devient directe et directe. Je pense que le maintien de deux tables serait difficile. Essentiellement, vous stockez toujours si un bon est utilisé ou non, mais vous ne le faites pas explicitement. Je suis sûr qu'il pourrait y avoir une solution de contournement, mais je pense que ce que j'ai décrit ci-dessus est beaucoup plus simple. Selon mon expérience, c'est le chemin que j'ai choisi à chaque fois face à un problème similaire.