isdeleted 历史物料 的处理 , invalid 物料 ,,, 用 新的关系表字段 替代 类型字段

总结: 无论用外键(关系表), 还是用类型字段;  实体的集合含义都已经改变了;

用关系,多一个历史实体, 不仅在原实体表上会增加一行,还会在关系表上增加了一行 ,getCurrent 外键为null ,isDeleted外键 有值;;

用类型,也会在原来的关系表是增加新的一行,类型为isDeleted ;

但是很奇怪, 一个实体上有两个外键,这两个外键竟然必须是相同的, 而且互斥 那为什么不用一个更合理;; 仅仅是为了大部分查询不用 is_deleted 附加;

ad上有两个外键,因为 广告主 和代理商是两个共存的变量,可以不同 ,同时存在

如果对一个实体表, 增加isDeleted 字段 , 这样就把历史, 过期的物料也加了进去;

这样以后每次用sql都需要把isDeleted这个字段加上去, 不然就会有问题;;

这样太麻烦了;;

好的原则是,从实体的角度;

ad有三个位置,每个位置有三个物料单元;

1`.位置有多个物料历史;

2 .一个位置有一个物料; 

现在位置物料融合为一体:那么第一句话就变成了 

1. 一个物料有多个物料历史;

现在有两种ormapping方案 , 

1.通过一个字段@where ,缺点,大部分业务逻辑都是针对现有物料,而非deleted物料,历史物料;

2.通过一个新的关系 ,附属到新的外键, historicalOwner 

如果附属在多表上,那么以后获取历史和现在的都比较容易, 利用 or ;

如果附属在关系表上,那么以后获取历史和现在的就需要通过unoin, union对不同表,相同表可以通过;

替换掉以后, 新增历史物料依然需要增加新的一行, 包括物料表,和 历史关系表; 

Material :

  private MaterialUnit materialUnit; //currentOwnerMaterialUnit
    private MaterialUnit historicalOwner;

MaterialUnit : 

 @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY, mappedBy = "materialUnit")
    @MapKey(name = "materialLayoutIndex")
    @OrderBy("id")
    @Where(clause = "is_enabled='1'")
    public Map<MaterialLayoutIndex, Material> getMaterials() {
        return materials;
    }


    public void setMaterials(Map<MaterialLayoutIndex, Material> materials) {
        this.materials = materials;
    }


    @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY, mappedBy = "historyMaterialUnit")
    @OrderBy("id")
    public List<Material> getHistoryMaterials() {
        return historyMaterials;
    }


    // hibernate only
    private void setHistoryMaterials(List<Material> materials) {
        this.historyMaterials = materials;
    }