Как сопоставить ассоциацию «многие ко многим» с классом, сопоставленным с двумя разными таблицами? - PullRequest
2 голосов
/ 02 ноября 2009

У меня есть ваучер - POJO сопоставлен с двумя таблицами. Первое сопоставление назначает имя объекта «voucherA» и сопоставляет POJO с TableA. Второе отображение использует «voucherB» в качестве имени объекта и отображает POJO в TableB.

Теперь у меня есть POJO клиента, сопоставленный с TableC. Этот POJO ссылается на ваучеры в списке.

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

Как правильно сопоставить список связей «многие-ко-многим» от клиентов с ваучерами, чтобы при сохранении POJO клиента сущности ваучера сохранялись в TableB, если их там нет, вместо TableA? Можно ли это сделать? Если нет, как будет выглядеть обходной путь, чтобы ваучеры, используемые клиентами, сохранялись в таблице B? (Таблица A содержит только доступные ваучеры, но не использованные)

Ответы [ 2 ]

3 голосов
/ 02 ноября 2009

Ваша базовая модель кажется неправильной. Ваша Voucher сущность предположительно имеет много атрибутов - ВСЕ ли они изменяются после того, как она используется Customer? Я сомневаюсь, что. И все же вы дублируете их в таблицах A и B, что означает, что ваша схема не нормализована.

«Доступный» ваучер и «использованный» ваучер не являются (или не должны быть) одним и тем же лицом. Вместо этого я бы предложил создать новую сущность для UsedVoucher, которая будет ссылаться как на Voucher как многие-к-одному, так и Customer как на многие-к-одному и содержать только "измененные" свойства Voucher ( если есть) Таким образом,

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
)

Ваше «многие-ко-многим» на Customer станет «один-ко-многим» (коллекции ваучеров, используемых этим клиентом), ЕСЛИ вам нужно это как обслуживаемое свойство; в противном случае его легко получить с помощью запроса.

Вы не можете физически удалить из таблицы Vouchers в этом сценарии, хотя (если рассматриваемый Ваучер никогда не использовался). Вместо этого вам придется выполнить логическое удаление.

1 голос
/ 02 ноября 2009

Мое предложение будет хранить все ваучеры в одной таблице. Чтобы различать используемые и неиспользуемые, вы можете иметь либо логический флаг, либо значение дискриминатора (если вы используете наследование в своем коде Java).

Даже если у вас есть существующие данные, похоже, что миграция будет очень сложной. Как только все ваучеры находятся в одной таблице, их отношение к клиентам становится простым для многих.

Я думаю, что поддержание двух таблиц было бы затруднительно. По сути, вы все еще сохраняете, используется ли ваучер или нет, но вы не делаете это явно. Я уверен, что может быть обходной путь, но я думаю, что то, что я изложил выше, намного проще. По моему опыту, этот маршрут я выбрал каждый раз, когда сталкивался с подобной проблемой.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...