1.业务需求决定是用1对多还是用多对1,因为可以在两边的任何一边设置关联
1)商品—类型：商品“多”这一方是主要信息,类型“1”这一方是基础数据字典,一般业务是取商品时获得相应的商品类型,业务表明要从“多”方拿到“1”方信息,配置上需要通过多对1来设置。表现在代码上就是商品类中有类型对象。
2)用户—地址：用户“1”这一方是主要信息,地址“多”这一方是用户的附属信息,一般业务是取用户时取相应的地址,业务表明要从“1”方拿到“多”方信息,配置上需要通过1对多来设置。表现在代码上就是用户类中有地址集合。

2.业务需求决定单向关联的还是双向关联：
比如商品—类型
1)业务上要求取得商品能够获取此商品的类型,维护商品的基本类型时不需要取得商品信息,表明只用从“多”方拿到“1”方信息,那么只用建立商品—类型:单向多对1关系。表现在代码上就是商品类中有类型对象。
2)业务上要求取得商品能够获取此商品的类型,维护商品的基本类型时的确不需要取得商品信息,但是加一个需求即要求能够找出此商品类型下的所有商品,表明既要从“多”方拿到“1”方信息,也要从“1”方拿到“多”方信息,那么必须建立商品—类型:多对1,类型—商品:1对多,的双向关系。表现在代码上就是商品类中有类型对象,类型类中有商品集合。注：如果完全按照面向对象的思路来设计实体之间的关系(即按现实世界模型之间关系)：商品有个类型属性,即获取商品时能够获取对应的属性,那么可以有商品—类型的多对1关系,但类型有多个商品这样的属性是不符合现实世界的模型关系的,因此严格按照面向对象,不应该有类型—商品的1对多关系。为了能够获取类型下所对应的商品,可以按类型查询商品表。
比如用户—地址
1)业务上要求取得用户能够获取此用户的地址,取得地址时不需要取得所属的用户,表明只用从“1”方拿到“多”方信息,那么只用建立用户—地址:单向1对多关系。表现在代码上就是用户类中有地址集合。
2)业务上要求取得用户能够获取此用户的地址,取得地址时要求能够获得所属的用户,表明既要从“1”方拿到“多”方信息,也要从“多”方拿到“1”方信息,那么需要建立用户—地址:1对多,地址—用户:多对1,的双向关系。表现在代码上就是用户类中有地址集合。地址类有用户对象。
可是实际生活中,用户—地址只可能是单向1对多关系,因为不存在列出所有地址,并获取每个地址所属的用户这样的需求。

3.多对多的几点
1)性能上肯定比拆成两个1对多要差点,但多对多更OO点,若拆成两个1对多在hibernate中还要自己维护中间对象,有点面向数据库建模的意思。
2)多对多关系最好建立双向关联,一般业务也是需要互相能够拿到对方的数据的,即使有一边不需要拿对方的数据,也设置成多对多,这样不用自己维护中间表。单向关联：删除被控方时要手动删除中间表记录。双向关联：删除被控方时由hibernate自动删除中间表记录。当然删除主控方时hibernate都自动删除中间表记录,因为主控方关联着被控方,“知道”被控方的信息(知道中间表外键的关联)。
备注：a-b多对多,a单向关联b,b不关联a,a是主控方,b是被控方。