我有两个表:
(1)songs(里面是歌曲的信息 包括歌曲名 歌曲类别id什么的)
(2)songType(里面只有两个属性 主键id 和歌曲类别名)
songs中有一个songTypeId(歌曲类别)的外键指向songType的Id由myeclipse反向工程得到的pojo类。songType自然映射成了一个类型为SongType 的引用类现在由于歌曲类别就那几种 不超过10种吧。但歌曲可以上1000了
歌曲类别信息先放入数据库了
然后添加歌曲信息时每首歌都要通过id把他对应的songType信息查出来放入songType的pojo类,实例化后赋给
Songs 的 songType属性, 然后再通过Hibernate save进去 感觉很麻烦 也很重复。如果用jdbc的话直接保存
一个外键id就行了。问题是:Hibernate实现这种需求的话有没有什么比较好的方法,一定要这样吗?
(1)songs(里面是歌曲的信息 包括歌曲名 歌曲类别id什么的)
(2)songType(里面只有两个属性 主键id 和歌曲类别名)
songs中有一个songTypeId(歌曲类别)的外键指向songType的Id由myeclipse反向工程得到的pojo类。songType自然映射成了一个类型为SongType 的引用类现在由于歌曲类别就那几种 不超过10种吧。但歌曲可以上1000了
歌曲类别信息先放入数据库了
然后添加歌曲信息时每首歌都要通过id把他对应的songType信息查出来放入songType的pojo类,实例化后赋给
Songs 的 songType属性, 然后再通过Hibernate save进去 感觉很麻烦 也很重复。如果用jdbc的话直接保存
一个外键id就行了。问题是:Hibernate实现这种需求的话有没有什么比较好的方法,一定要这样吗?
public class Songs {
private int id;
private SongType songType;
,,,,,,
}
改成
public class Songs {
private int id;
private int songTypeId;
}伴随着hbm配置文件也要给!
是怕hibernate的负担很重吗
那就考虑继承映射吧
加识别器
10个种类的歌曲 用XML文件中用10个pojo映射上
当然这样的话你的表结构也要改再大脑的逻辑是 我存的是一个种类 我取得却是一首歌
改改表的结构就得了
不过我觉得没什么必要
不知楼主出于何种考虑
优化效率语句?