1.1.1中一对一关系的特别地方

[Alex wang]

今天发现一个有意思的问题，假设有两个domain,A 和B 

class A {

String name

B b

}

这种情况假设要修改 b，def b = a.b ,此时用 b.save() 方法会报错，说B 没有save这个属性.

也就是说假如修改了B，必须通过A来保存

听说1.2中有专门的OneToOne显式标记，不知道是否有什么特别与1.1不同的地方。

[Phoenix]

1.2M4的Release Notes：
支持把外键放在Child而非Parent中。

Support for hasOne mapping

GORM now supports hasOne mapping where the foreign key is stored in
the child instead of the parent association. For example:

class Person {
String name
static hasOne = [address: Address]
}
class Address {
String street
String postCode

[Phoenix]

Sorry，漏了关键的一段：

In the above case a foreign key column called person_id will be
created in the address table rather than the default where an
address_id is created in the person table.

On 11月6日, 下午9时51分, Alex wang <idea.w...@gmail.com> wrote:

[Alex wang]

那么，外键何时放在parent,何时放在child? 有没有一定的标准呢？

一般来说都是放在parent里的，比如一个订单里有一个用户信息，那么Order里一般就会有一个user_id字段，如果反过来，是什么情景下使用呢？

2009/11/12 Phoenix <winters...@gmail.com>

[TigerF]

Order 和 User 的关系不是1对1的，只能放在Order中。

1对1我用到过一次，在一个项目中设计User类，我把一些必要的属性放在User中。然后把一些零碎的东西，像地址、邮件、电话、爱好等等，放在 UserInfo中，这些数据可以完全没有。当时觉得间接使用UserInfo比较多，就把外键放在User表中的。

不过后来我还是倾向于把两个表合并了。

Alex wang 写道:

[Alex wang]

呵呵，看来我对一对一的关系理解有偏差啊。 thanks.

按照你刚才举例的User和UserInfo，我有一个问题，对于将外键放在User或者是放在UserInfo,对最终的业务使用方式上有没有什么不同的地方？ 都能够通过user访问到UserInfo?

2009/11/12 TigerF <tig...@gmail.com>

[TigerF]

业务上绝大部分都只使用User，有个别的地方需要先查询UserInfo的。我做了个联接查询，连User一块查了，这个地方应该算是有性能浪费。

Alex wang 写道:

呵呵，看来我对一对一的关系理解有偏差啊。 thanks.

按照你刚才举例的User和UserInfo，我有一个问题，对于将外键放在User或者是放在UserInfo,对最终的业务使用方式上有没有什么不同 的地方？ 都能够通过user访问到UserInfo?

[Ali Yang]

用的时候再查了，不算是性能浪费吧

2009/11/12 TigerF <tig...@gmail.com>

业务上绝大部分都只使用User，有个别的地方需要先查询UserInfo的。我做了个联接查询，连User一块查了，这个地方应该算是有性能浪费。

--
Ali Yang
----------------------------------------
Blog: http://ssailyang.javaeye.com
Twitter: https://twitter.com/aliyang
MSN: yang_...@hotmail.com
QQ: 407131746
----------------------------------------

[Alex wang]

还是合并的比较好，事比较少，性能也会提高，分开仅仅是看上去很美，大家觉得呢？

2009/11/12 Ali Yang <yang...@gmail.com>

[Alex wang]

咋一看感觉User和UserInfo分开不合理，细一看，还不如咋一看呢  囧

2009/11/12 TigerF <tig...@gmail.com>

[TigerF]

我后来就是这个感觉

Alex wang 写道:

还是合并的比较好，事比较少，性能也会提高，分开仅仅是看上去很美，大家觉得呢？

2009/11/12 Ali Yang <yang...@gmail.com>

用 的时候再查了，不算是性能浪费吧

2009/11/12 TigerF <tig...@gmail.com>

业务上绝大部分都只使用User，有个别的地方需要先查询 UserInfo的。我做了个联接查询，连User一块查了，这个地方应该算是有性能浪费。