做面向对象设计的时候，我们常常面对这样一个问题。当对象之间存在一对多关系的时候，在物理设计的时候应该选择一对多关系还是多对一关系？举例来说，假设有一个订单对象，每个订单对象对应多个订单条目。这个时候我们在设计的时候有两中选择，一种是在订单对象中加入一个订单条目集合，另外一种方法是在订单条目中引用订单对象。分别对应以下两种设计。
最简单一种方法是同时保留两种关系，也就是既在订单对象中保留订单条目集合，也在订单条目上引用订单对象。这也是很多根据数据库生成对象模型的工具的默认选择。但是这样做存在一个性能问题，很多OR Mapping的工具在保存具有一对多关系的对象时，都会将“多方”的对象每个都重新保存一遍（以Nhibernate为例，如果订单对象引用了订单条目对象的集合，那么如果在保存订单对象时，订单对象是脱钩对象，Nhibernate会把所有订单条目对象重新保存一遍）。
从上面的例子可以看到，使用一对多关系在很多情况下，在很多情况下都会引入性能问题。那是不是可以说在做对象设计的时候不要使用一对多关系，每次仅使用多对一关系就可以了呢？答案当然是不。那什么时候可以使用一对多关系呢？主要有两中情况，第一种情况是，一对多关系中的多方在保存时需要参照多方中其它的对象，才可以确认是不是可以保存。还是以订单对象为例，假设订单条目对象有一个金额，如果每个订单下的订单条目金额的总和不能超过一个特定的值，这种情况下一定要使用一对多关系。因为单独看一个订单条目的情况无法确认该订单条目是否可以保存，而每次保存都把和该订单条目在同一订单下的所有订单条目读出来，而且还要避免保存冲突问题需要大量的代码，这种情况下就不如使用一对多关系了。另外一种情况相对比较少见，那就是多方的对象直接的顺序有严格的要求，这种情况也必须使用一对多关系。这种情况在开发工作流设计器时经常会出现，每个工作流会有多个活动，而活动的执行顺序是一个很重要的属性，如果出现问题会导致工作流整体执行的异常。必须保证工作流与工作流活动的每次保存都是整体保存，如果两个人同时保存了一个工作流，即便保存的是不同的活动，只要调整了活动的顺序，都可能会让整个工作流的执行顺序出现异常，这种情况下最好也是使用一对多关系。