比方说，我有一个看起来像一个Grails域类
class Person {
Address address
}
我还可以声明为
class Person {
static hasOne = [address:Address]
}
第二种方式将移动的外键的地址表，而不是人的表。
什么是这样做的一种方式VS其他的实际利益（或缺点）？ 据我了解，他们都将使用外键，它只是一个地方的外键的生活问题。
Answer 1:
如果在地址表中存在的外键，则该地址只能有一个人。 如果外键是对人表，多者可有相同的地址。
这不是什么样的方式比较好/差。 这是关于什么是你的数据模型的正确方法。
Answer 2:
我发现使用hasOne Grails中是特别混乱。 例如，这个问题问时TOONE关系声明如下发生了什么：
class Person {
static hasOne = [address: Address]
}
如上所述，这将导致person_id外键出现在地址表中，这意味着每个地址可以在一个人只点。 我发现了什么奇怪的，那么，即使代码被写成“一个人有一个地址”，实际的结果是，“一个地址有一个人”。
而事实上，如上文所限定，没有什么（在数据库级别）防止多个地址记录从同一个人，这意味着一个人不一定真的要有一个地址后，所有指向。
有趣的是，你会得到相同的数据库表示，如果你创建了Address类是这样的：
class Address {
Person person
}
在person_id外键会在地址表中，就如同像在前面的例子，但显然，你不能从人到代码的地址没有定义在某种程度上这种关系也得到。
同样有趣的是，如果你从建模人物A一对多关系数据库地址，你会使用相同的表格布局。 你把父母的主键（为person_id）到子表。 从数据库的角度来看的话，使用hasOne创建一个一对多的关系会产生相同的结构。
当然，我们不只是在创建数据库表，我们正在创建一个具有与其相关的一些行为和关系语义的一些执法Grails领域类。 在这个特定的业务例如，你可能不希望与多人分享同一个地址的记录，你只是想单独存储地址（也许有一天准备当一个人有多个地址）。 我可能会投票支持这种做法：
class Person {
Address address
static constraints = {
address unique:true
}
}
该address_id外键将在Person表，以及独特的约束将强制执行，没有两个人记录在同一个地址指向。
Answer 3:
我建议以下...
class Person {
...
static hasOne = [address: Address]
}
class Address {
...
static belongsTo = [person: Person]
}
一个人有一个地址，该地址属于一个人。
通过这种方式，当你删除一个人，该地址也将被删除，没有任何问题。
我认为这是更好的方式来做到这一点。
Answer 4:
该人 “hasOne” 地址和地址 “ 属于关联 ”的人 。
有关于“子”表的外键更有意义，因为这样一来，如果家长缺少孩子会打破。 一个人可以不存在的地址，而是“人的地址”没有一个人是没有意义的。 因此， 地址应该是关系较弱的一方。
这样做，这样在Grails的两个实体将有参考彼此也不会觉得奇怪。 也是默认的级联行为将保存和删除的地址 ，当你保存人 ，但如果你想删除的人会继续留保存的地址 。
文章来源: grails hasOne vs direct member variable
