java当访问模式依赖于一对多时,如何处理POJO中多对多表中的附加属性?
CREATE TABLE order (
order_id INT
,...
,CONSTRAINT ... PRIMARY KEY (order_id)
);
CREATE TABLE item (
item_id INT
,item_list_price DECIMAL(10,2)
,...
, CONSTRAINT ... PRIMARY KEY (item_id)
);
CREATE TABLE order_item (
order_id INT
,item_id INT
,order_item_current_price DECIMAL(10,2);
,CONSTRAINT ... PRIMARY KEY (order_id, item_id)
,CONSTRAINT ... FOREIGN KEY (order_id) ...
,CONSTRAINT ... FOREIGN KEY (item_id) ...
);
一个Order
有许多Item
;每个Item
可能属于许多Order
一个Item
的价格可以随时改变。为了让客户检查他过去为Item
支付了多少钱,在order_item
表中存在order_item_cost
字段
当最终用户检查Item
的待售商品时,它将提取一个包含商品id、名称和标价的商品列表,而不是当前价格(因为当前价格仅与order
的历史报告相关,而不是购买新的item
)
当客户希望检查其历史购买情况以及他当时为每个项目支付的费用时,它将使用项目列表(包括项目id、名称和currentPrice,但不包括listPrice)拉取订单(因为listPrice仅与购买新项目相关,而不与历史报告相关)
因此,尽管我的关系模式在订单和项目之间存在多对多关系,但我的POJO认为订单和项目之间存在一对多关系,因为永远不会有需要多对多的访问模式
以下是我目前的POJO(精简为简洁):
public class Order {
private int id;
private String status;
private Customer customer;
@OneToMany(mappedBy="order")
private List<Item> items;
...
}
public class Item {
private int id;
private String name;
@ManyToOne
private Order order;
private double listPrice; // List price of item, capable of changing over time
private double currentPrice; // represents the order_item_cost field in order_item table
...
}
正如您所注意到的,我没有将List<Order>
放在Item
类中,因为我无法想象需要知道购买的和Item
使用过的所有可能的Order
然而,这感觉是错误的。我想知道是否应该从Item
中取出currentPrice
成员变量,并创建一个名为OrderItem
的新POJO,它反映了order_item
表:
public class OrderItem {
private Order order;
private Item item;
private double cost;
}
public class Order {
@OneToMany(mappedBy="order_item")
private List<OrderItem> orderItems;
}
public class Item {
@OneToMany(mappedBy="order_item")
private List<OrderItem> orderItems;
}
但是,同样,访问模式永远不需要一个条目来查找与之关联的所有订单。Item类是否应改为类似于:
public class Item {
@OneToMany
private Order order;
}
或者,有没有更合适的方法使用Hibernate来处理这个问题
总之:我的DB有一个多对多模式,因为一个item
可以属于多个order
,每个order
可以有多个item
,我希望记录客户当时购买物品的价格,因为item
的标价可以更改。然而,我的应用程序的访问模式只要求它看起来像order
和item
之间的一对多关系。我不确定POJO或hibernate应该如何处理这个问题
# 1 楼答案
您肯定需要对OrderItem对象建模,因为它是一个具有自己属性(成本)的关系对象。您应该为订单1建模->;n订单项n->;1项。DB的建模应该类似于订单不包含项目,因为价格不是项目价格,而是订单项目价格