JAVA两个表相关联_关于Java：如何将多对多关联映射到映射到两个不同表的类？...

我有一个凭证-POJO映射到两个表。 第一个映射分配一个实体名称" voucherA"，并将POJO映射到TableA。 第二个映射使用" voucherB"作为实体名称，并将POJO映射到TableB。

现在，我还有一个映射到TableC的客户POJO。 该POJO引用列表中的凭证。

我如何正确映射从客户到凭证的多对多关联列表，以便如果持久存储了客户POJO，则如果凭证实体不存在于表B而不是表A，则凭证实体也将持久化到表B？ 能做到吗？ 如果不是，一种解决方法是什么样的，以便客户使用的凭单可以持久保存到tableB？ (TableA仅包含可用的凭证，不包含已使用的凭证)

只是为了澄清一下，您是否对每种凭证都使用表格？将两种类型的凭证存储在一个表中是否会被接受？

第二个表应仅包含已使用的凭证。同样在我的情况下，一张凭证可以由不同用户多次使用。在我的问题中，TableA可能无法理解为"仍可以使用的凭单"，而TableB可以被理解为"已使用的凭单"。还可能发生TableA的凭单被删除的情况。我坚持如何创建多对多关联。

我懂了。如果您在表中为每个凭证存储了一个标志(如果使用该凭证，则为true，否则为false)是否会不可接受？我认为通过这种方式，您仍然可以随意删除未使用的凭证，但是您可以将所有凭证放在同一张表中，这使多对多微不足道。

我的首选是两张桌子的灵魂，但是如果这不可能或太复杂而无法实现，我将选择一张桌子

谢谢您的澄清。我确实认为这是最简单的路线。您可以在下面找到我的"官方"答案。

您的核心模型似乎有问题。您的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表中物理删除(除非从未使用过相关的凭证)。您必须改为进行逻辑删除。

我同意你的回答。 顺便说一句，选择具有非规范化架构有时是合法的。 使用Hibernate，代码中的设计会严重影响架构。 您的问题可能是，如果您使用每个子类表继承，则更容易做一些事情。 做出选择通常意味着您将要复制数据。 因此，我会毫不夸张地说该模型是"错误的"。

柳德米尔(Lyudmil)-有不同种类的非正规化，一些比其他更容易接受。 但是，在这种情况下，基于我对OP想要什么的理解(他还不太清楚，说实话)，我绝对会建议不要将所有内容捆绑在一张桌子中。 您最终将获得"基础"凭证和多个"已声明"凭证，从而导致无法具有任何有意义的FK /业务密钥约束。 此外，根据我的理解，我再次说"似乎不对" ：-)。

我的建议是将所有凭证存储在同一张表中。要区分使用的和未使用的，可以使用布尔标志或鉴别符值(如果在Java代码中使用继承)。

即使您已有数据，迁移似乎也不是一件容易的事。一旦所有代金券都放在同一张桌子中，它们与客户的关系就变成了直接的多对多关系。

我认为维护两个表将很困难。本质上，您仍在存储是否使用了凭证，但是您没有明确地进行使用。我敢肯定会有解决方法，但是我认为上面概述的要简单得多。以我的经验，这是我每次遇到类似问题时都选择的路线。