[SEAM] 请教一个好象有点麻烦的问题
 |
bigcatJavaEye
2008-03-07
现在项目中有这样一个不太规范的表
如下：再同一张表里面车库和汽车的信息，1对n关系。
table:
----------------------------------------------------------
storeId storeName storeAddr carId carType carColour
001 东库 大连 001 ABC red
001 东库 大连 002 TRE red
001 东库 大连 003 ATT red
----------------------------------------------------------
key1:storeId
key2:carId
现在要求表里面对应出两个model, store(key:storeId)和car(key:carId).这两个model是1对n的关系。做store来mapping. store有个carList属性。 会出现下面两个问题： 1 如果只修改storeId为001的storeName,就是要求ORM找到所有storeId为001的纪录，把他们的storeName全部改掉。hibenate有没有一次处理多条数据的功能？001的纪录有多条的话它直接报错。 2 即使我做出来了一个对象，store带个carList，怎么保存？因为保存的时候，DB生成的纪录数目应该是carList的长度。hibenate有没有这功能？ 不知道各位有没有碰到类似情况。（说明有不清楚的地方请提出） |
 |
pf_miles
2008-03-07
这个表还没到三范式，可能为了争取性能，牺牲了空间。不知道你们目前的应用大不大，够大的话这样所有字段都放一个表里很快会成为瓶颈。
从业务的角度讲，“第一种方案”我觉得是没有道理的，不知道你怎么考虑它。既然要用seam，图的就是OO，快速，以及中间（业务）管两边（view和数据）。我觉得一个store对应多个car是比较好理解的。开发维护会更顺手。 不知道你提出“第一种方案”的理由是什么？ |
|
bigcatJavaEye
2008-03-07
pf_miles 写道 这个表还没到三范式，可能为了争取性能，牺牲了空间。不知道你们目前的应用大不大，够大的话这样所有字段都放一个表里很快会成为瓶颈。
从业务的角度讲，“第一种方案”我觉得是没有道理的，不知道你怎么考虑它。既然要用seam，图的就是OO，快速，以及中间（业务）管两边（view和数据）。我觉得一个store对应多个car是比较好理解的。开发维护会更顺手。 不知道你提出“第一种方案”的理由是什么？ 第一种方案其实就是凑下面帖子的例子的，起码可以实现两个model。 http://topquan.iteye.com/blog/67490 第二种方案想不出来怎么实现。 store组件在插入的时候，它怎么知道根据自己属性carList的数量把自己变成多个的。 感觉不太符合 “组件instance对应table的record”这个原则。 |
|
pf_miles
2008-03-07
bigcatJavaEye 写道 pf_miles 写道 这个表还没到三范式，可能为了争取性能，牺牲了空间。不知道你们目前的应用大不大，够大的话这样所有字段都放一个表里很快会成为瓶颈。
从业务的角度讲，“第一种方案”我觉得是没有道理的，不知道你怎么考虑它。既然要用seam，图的就是OO，快速，以及中间（业务）管两边（view和数据）。我觉得一个store对应多个car是比较好理解的。开发维护会更顺手。 不知道你提出“第一种方案”的理由是什么？ 第一种方案其实就是凑下面帖子的例子的，起码可以实现两个model。 http://topquan.iteye.com/blog/67490 第二种方案想不出来怎么实现。 store组件在插入的时候，它怎么知道根据自己属性carList的数量把自己变成多个的。 感觉不太符合 “组件instance对应table的record”这个原则。 有意思...“组件instance对应table的record”是什么原则？组件实例的数据确实来源于一个或多个数据库表的record，但不是你说的那种一个萝卜一个坑的对应关系，是有差异的，这种差异来源于OO模型和E－R关系模型的差异，所以才需要O－R mapping。 “store组件在插入的时候，它怎么知道根据自己属性carList的数量把自己变成多个的。” 不知道你是否试图在seam中整合ibatis，否则这个问题是不需要考虑的：如果你用EJB3.0作persistence，那么OneToMany和ManyToOne结合Table，Column annotation会为你解决这个问题；如果你用Hibernate，那么你也只需要在映射文件里把这个对应关系描述清楚就行了，你不必关心“它怎么知道根据自己属性carList的数量把自己变成多个的”。 就算你真的用ibatis,也很好想吧——对于这个store对象中的每一个car对象，都携带一个storeId插入数据库，最后update 你的表 set (......) where storeId=#这个storeId# |
|
pf_miles
2008-03-07
另外，只要你打算OO，那么不管怎么设计，都应该有2个model：store和car,如果没有，那么就不算OO。
|
|
bigcatJavaEye
2008-03-07
pf_miles 写道 另外，只要你打算OO，那么不管怎么设计，都应该有2个model：store和car,如果没有，那么就不算OO。
to:pf_miles 谢谢你的回复. 我实现一下看看. |
|
bigcatJavaEye
2008-03-07
不好意思呀,还是没整出来。
能不能实现一下瞅瞅。可能用代码更好讲解一些。 谢谢先。 |
|
pf_miles
2008-03-07
bigcatJavaEye 写道 不好意思呀,还是没整出来。
能不能实现一下瞅瞅。可能用代码更好讲解一些。 谢谢先。 正好我也正学习这个框架，可以做一个例子给你看，不是很难，但我想我不得不先解决这个问题：http://seam.group.iteye.com/group/topic/4419 |
|
pf_miles
2008-03-09
例子已经做好了，我抽空发到我的blog上吧～好久没写文章了。
|
 |
xxqn
2008-03-09
我的项目中放弃使用表格深度继承，继承关系手动实现更加能够保证性能。如果遇到你这种情况，建两个表就成了，
store表 storeId storeName storeAddr car表 storeId carId carType carColour 如果你的数据不是太多可以使用OneToMany和ManyToOne，这样关系更加清晰 |
