今天模仿手机商城的时候, 大胆想出了使用集合'嵌套'
private List<List<Xxx>> xxx; // 两个不确定 (第一层属性不确定, 第二层属性不确定)
场景:
首页展示出不同的大类, 像iphone 6s, 华为8x, vivo10等这种大分类
点击一个大分类, 进去展示出不同颜色, 套餐, 配置等的小分类
注: 只要有一点不同, 就是一种小分类, 比如颜色有3种, 套餐有2种, 配置有3种, 则小分类就有3*2*3种(一种小分类有一个编号)
一种小分类可能有不同的赠品或套餐携带物品(以下统称小物件)
比如编号为201805121201的手机赠送某耳机
编写为201805121202的手机赠送某手机保护壳和某运动手环
意思是每种手机可能有不同的小物件(如果某种手机销量差, 可以考虑增加赠品来促销)
这中间的关系链其实是比较复杂的, 想表示清楚并不容易
思路:
根据面向对象的想法, 将手机设计成类型
小物件也设计成类型
小物件是与手机关联的, 所以将小物件设计为手机的属性
因为一部手机关联的小物件的各类是不确定的, 所以将小物件设计为手机的集合属性
对于某种小物件, 它可能有不同的颜色, 所以还要使用集合表示(这个最难理解)
如下示意图就明白了
荣耀v10 -- 某种品牌手机(一个手机对象)
运动手环/硅胶保护壳/... -- 赠品大类(不确定有多少种赠品, 根据查询得出)
黑.红...运动手环 / 黑.白.青...硅胶保护壳 / ... -- 细化赠品(不确定每种赠品有多少个小类, 根据查询得出)
所以做如下属性设计是比较合理的:
@Entity
@Table(name="cell")
public class CellPhone implements Serializable {
//... 其它的数库库字段
@Transient // 标识此属性不是数据库字段
// 一个手机可能包含多种的赠品, 每种赠品可能有多种颜色等(在构造手机时需要用到)
private List<List<Additional_goods>> sendGifts;
@Transient
// 一个手机可能包含的套餐物品(套餐物品与赠品都是同一类型)
private List<List<Additional_goods>> setMealGift;
}
1.创建手机大类型数据表(一般是首页或大页面展示的信息):
2.创建手机详情数据表时, 应该使用字段表示出小物件:
set_meal是套餐携带物品, presenter_gift是赠品, type_id表示该手机所属的大类
每一条记录表示一种手机, 也可以看到每种手机的小物件不全相同的
第一条记录套餐携带1, 赠品为2 // 1,2这是小物件的id, 根据它能查询到小物件信息
3.创建小物件数据表(大类型):
创建小物件详情数据表(根据type_id关联):
总的关系: 两个手表(手机类型表, 手机详情表), 两张小物件表(小物件类型表, 小物件详情表), 通过手机详情表关联
访问可得到数据(集合在前端表示为数组):
