大家好！
我在做一个相册，每个相册中可能有n张照片。目前相册与照片也配置成了双向一对多的关系。但我一直担心会出性能问题。
因为我发现好像用hibernate3的JPA配置里面，无法将一的一端设为“inverse”。所以如果添加相片，必须这样：
photo.setAlbum(album);
album.getPhotos().put(photo);
albumManager.save(album);
这样每添加一张照片，就要获取一遍该相册中的所有相片！
有没有更好的办法？
比如将相片和相册设置成单向多对一？
或者干脆不配置关联，直接用程序逻辑控制关联？（我以前都是这么做的，但现在发现ORM的精髓就是关联，不配置关联实在可惜）
或者用大缓存解决这种问题？（总感觉不太合适，而且我们现在没有钱购买很贵的机器，如果非要这样的话，我觉得hibernate在这一点设计的也太烂了吧？）
刚还看了下面这篇帖子，跟我问的问题差不多，但几乎没有人能给予一个很肯定并且很有说服的答复。
http://www.iteye.com/topic/59707?page=1
恳请各位热心的大侠给予答复，谢谢！
问题补充
herowzz 写道
photo.setAlbum(album);
photoManager.save(photo);
photoManager.save(photo);
这个写法的前提是photo作为一对多关系的主控端吧！
但是我设置album和photo的双向一对多关系时，发现好像只能是由album作为主控端，查了很多资料也是这么写的。。。
而以前用多对多关系的时候，两边谁做主控端都可以的。
一对多却只能一的一端做主控端，所以很苦恼！
不知道上面的兄弟是如何做到让photo做一对多关系维护的主控端的。
p.s. 我的配置如下：
@Entity
@Table(name="alb_album")
public class Album implements Serializable {
private Set<Photo> photos = new HashSet<Photo>();
@OneToMany(cascade=CascadeType.ALL,mappedBy="album",fetch=FetchType.LAZY)
public Set<Photo> getPhotos() {
return photos;
}
public void setPhotos(Set<Photo> photos) {
this.photos = photos;
}
}
@Entity
@Table(name="alb_photo")
public class Photo implements Serializable{
private Album album;
@ManyToOne(cascade = { CascadeType.MERGE, CascadeType.REFRESH })
@JoinColumn(name="album_id")
public Album getAlbum() {
return album;
}
public void setAlbum(Album album) {
this.album = album;
}
}
