多态STI设置

我有一个正在广泛使用实体模型的应用程序。多态STI设置

在这个应用程序的过去版本（工作在重写，当前版本在PHP中），这是用单个表基于两个相同的模型进行建模。

一个模型是实体，它与项目相关联并且具有多种类型（客户端，请求者，提供者等）。
另一种模式是地址簿，它与实体大部分相同，除了不同的表格和型号名称以及少数地址簿字段（如禁用）。

目前我们对实体列addressbook_id项目实体映射回地址簿，或做不到这一点，我们尝试基于电子邮件地址做一个映射。地址簿和实体之间的数据不会保持同步，也就是说，必须能够更新项目中的实体，而不会影响地址簿中的数据（尽管我们也提供了更新地址簿的选项）。

无论如何，有4或5种类型的实体。他们大多具有相同的字段（名字，姓氏，电子邮件，地址，电话等）。每个实体类型可能有1 - 3个独特的字段，但这就是它。除此之外，目前的应用实体可能是人或公司（同样的STI表，其中也有一个company_name字段）。

对于哪些应用程序需要做的，很容易能够找到的所有实体的一个项目（不论类型或他们是否是人或公司）是一个双赢。还能够轻松地加入实体在查询和搜索他们每个项目，双赢。

正因为如此，我倾向于坚持STI模型，并保持它的简单，而且由于每类股90％相同的字段的它不是一个很大的浪费。然而，我很好奇是否有任何好的建议来处理地址簿和实体基本相同的模型，但将数据保存在单独的表中的问题。我已经考虑了多态关联如何可能会有所帮助，但我认为这会使表结构更复杂，并可能会影响查询的性能（相当大的数据集，这些实体可能包含在列表视图中）。

但我真的不想跟这结束了......

class Entity 

class Customer < Entity 

class Addressbook 

class AddressbookCustomer < Addressbook 

etc...

不是非常干燥，并有实体型和亚型之间的共同功能（例如，实体和通讯录都将有一个返回完整名称的名称方法，并且Customer和AddressbookCustomer可能都有一个last_order方法）。

目前只是存储在两个表，地址簿和实体，其具有类型列中的数据。然而，这是一个完全中断使传统的表结构没有被保留，但是从保持简单我做这样的结构的角度。

有什么建议吗？

来源

2011-03-05 Chad

我从来没有这样做，但如果你想在所有你的“实体”的共享代码为什么不创建一个基类，一切继承：

class OneClassToRuleThemAll < ActiveRecord::Base 
    def name 
    ... 


class Entity < OneClassToRuleThemAll 
    set_table_name "entities" 

class AddressBook < OneClassToRuleThemAll 
    set_table_name "address_books"

这就给了你一个基类共享方法，但为继承树中的每个分支分开表。

如果你不喜欢这个解决方案，因为你仍然想共享不属于OneClassToRuleThemAll的方法，但是它们是在树下的堂兄类之间共享的，那么为什么不写一个小模块来保存这些函数，如last order，然后只需将该模块导入每个需要这些函数的表亲类中？

P.S.我甚至不知道第一个例子是否可行，但我认为它应该。

来源

2011-03-05 06:18:23 jakeonrails

回答

相关问题