我遇到了模型（地址）和具有此数据的多个模型（公司，人员）的典型情况。让我们以这些模型为例，但可以与其他模型一起推广。
做出正确的选择很重要，因为稍后更改数据库架构或进行深度更改并不容易。
最初它将是一对一的关联，然后我们有这些可能性：
1）使用经典归一化并将所有地址数据放入需要它的每个模型中。然后创建一个地址子表单，将render部署到每个子表单中，并将代码行为放入一个Module中，使用它从每个模型控制器调用。
这可能看起来很好，但是它存在难以进行更改的问题，因为需要在使用它的每个模型上对地址数据进行任何更改。如果需要，也很难将其更改为一对多关联。
2）Rails多态特征。 Address是一个模型本身，并且belongs_to：addressable，polymorphic：true，那么Company和Person有has_one / has_many：address /：addresses，as：addressable。然后将多态FK添加到Address表中并完成。
我喜欢这个解决方案，很明显，只有2个额外的列我们已经完成了它。我能想到的唯一反对意见是我们依赖于框架功能，所以如果有一天我们迁移到另一个，它也应该具有多态性。这不是真的，因为我们总是可以通过addressable_type =“type”手动搜索SQL，但我认为这不是数据库设计标准。
3）加入表格。每个父母一个。所以我们有JT_Company_Address，JT_Person_Address，我们使用Rails has_one / has_many：通过使用这些连接表的关联。
我认为使用连接表是更多的数据库设计标准，但添加了一些额外的表。
4）颠倒关系，使地址成为父母，另一个成为孩子。所以每个孩子都有一个FK address_id 我不喜欢这个，因为我将主要处理公司和人员，然后在需要时查找他们的地址，而不是相反的，寻找地址，然后循环它的内容。我们总是可以使用Rails inverse_of来使用bidiriectional关联，但是在数据库层，Address将是父级的任何一个。
此刻我最喜欢的是2和3.我可能会使用Rails而不是从它移动，因此多态看起来非常简单和干净。
然后，你怎么看，哪一个是最好的？欢迎任何建议。 感谢。