Wie viele-zu-viele-Verein zu einer Klasse zu zwei verschiedenen Tabellen abgebildet abzubilden?

Question

Ich habe einen Gutschein - POJO zu zwei Tabellen abgebildet. Die erste Abbildung weist eine Entität Namen „voucherA“ und bildet die POJO zu TableA. Die zweite Abbildung verwendet „voucherB“ als Entitätsname und ordnet den POJO zu TableB.

Jetzt habe ich auch einen Kunden POJO zu TableC abgebildet. Diese POJO Referenzen Gutscheine in einer Liste an.

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

Wie ordne ich richtig eine Liste von many-to-many-Verbänden von Kunden Gutscheine, so dass, wenn ein Kunde POJO beibehalten wird, werden die Voucher Einheiten zu TableB beharren, wenn sie nicht existieren, statt TableA? Kann dies geschehen? Wenn nicht, was aussehen würde eine Abhilfe wie so dass von den Kunden verwendeten Gutscheine werden auf tableB anhielt? (TableA enthält nur Gutscheine, nicht die Gebrauchten)

Answer 1

Ihr Kernmodell scheint falsch. Ihre Voucher Entität hat vermutlich viele Attribute - tun alle von ihnen zu ändern, nachdem es von einem Customer verwendet wird? Ich bezweifle das. Und doch sind sie in Ihren A und B Tabellen duplizieren, was bedeutet, Ihr Schema nicht normiert ist.

„Verfügbar“ Gutschein und „gebraucht“ Gutschein nicht (oder nicht sein soll) die gleiche Einheit. Ich würde stattdessen vorschlagen, dass Sie eine neue Einheit für UsedVoucher erstellen, die so viele-zu-eins und Voucher so viele-zu-eins und enthält nur „geändert“ Eigenschaften von Customer (falls vorhanden) sowohl Voucher verbinden würde. Also,

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
)

Ihre „many-to-many“ auf Customer wird „one-to-many“ (Sammlung von Gutscheinen dieses Kunden verwendet), wenn Sie es als wartbar Eigenschaft benötigen; ansonsten ist es über Abfrage leicht auffindbar.

Sie können von Vouchers Tabelle unter diesem Szenario nicht physikalisch löschen, wenn (es sei denn Gutschein in Frage nie verwendet wurde). Sie werden stattdessen eine logische löschen zu tun haben.

Answer 2

Mein Vorschlag würde alle Gutscheine in der gleichen Tabelle zu speichern sein. Zur Unterscheidung zwischen gebrauchten und nicht benutzten könnten Sie entweder einen boolean-Flag oder einen Unterscheidungswert (wenn Sie mit Vererbung in Java-Code).

Auch wenn Sie Daten über vorhandene es scheint nicht, wie die Migration furchtbar schwierig sein würde. Sobald alle Gutscheine sind in der gleichen Tabelle, ihre Beziehung zu den Kunden wird ein Straight-Forward-many-to-many.

ich denke, zwei Tabellen beibehalten wäre schwierig. Im Wesentlichen sind die Speicherung Sie noch, ob ein Gutschein verwendet wird oder nicht, aber du bist es nicht explizit tun. Ich bin sicher, es könnte ein Problem zu umgehen sein, aber ich denke, was ich oben beschrieben ist viel einfacher. Meiner Erfahrung nach ist dies der Weg, den ich jedes Mal, wenn sie mit einem ähnlichen Problem konfrontiert gewählt habe.