对象关系数据库中的联接表继承映射与组合

Question

我最近开始使用SQLAlchemy，而不了解SQL。我一直面临的一个问题是如何引入多态行为。作为一个例子，考虑类似Reddit的web应用程序；我们有一个Article和一个Comment的模型，这两个模型都可以投票表决：

class Article(Base):
    id       = Column(Integer, primary_key = True)
    data     = Column(Text)
    comments = relationship('Comment')
    #... more article-related attributes
    votes      = relationship('Vote')
    vote_ups   = Column(Integer, default = 0)
    vote_downs = Column(Integer, default = 0) 

class Comment(Base):
    id   = Column(Integer, primary_key = True)
    data = Column(Text)
    #... more comment-related attributes
    votes      = relationship('Vote')
    vote_ups   = Column(Integer, default = 0)
    vote_downs = Column(Integer, default = 0)

我想分离投票属性，这两个模型都是通用的，这样我就不必为每个可以投票的模型重复代码。在

我的第一个想法是创建一个新的VotesComponent模型，包含这样的属性

^{pr2}$

并建立了Comment和{}模型的多对一关系。在

在钻研SQLAlchemy文档之后，我发现使用joined table inheritance可以实现类似的功能。一开始这看起来真的很方便，因为避免了额外级别的间接寻址（即可以引用评论。投票而不是comment.vots\u组件.voices），但我在有限的理解中看到了一个很大的缺点，即不支持多重继承，而使用早期的方法，可以随意添加任意多个“组件”一个模特。在

所以，我的问题是，在组合中使用继承映射有什么好处，什么时候更可取？为什么？在这种情况下，您会推荐两种（或者可能不同）方法中的哪一种？在

编辑：我需要指出的是，我希望能够单独查询模型的“投票”部分，以便能够以多态方式处理投票。在

Answer 1

这是一个很好的问题，但在这里与主题无关，因为在stackoverflow上，那些需要基于观点的答案的问题是不受欢迎的。也就是说，这是我个人的看法（我真的不想引发一场激烈的战争）。在

So, my question is, what are the benefits of using inheritance mapping over composition, and when is either preferable and why?

在大多数OO语言中，继承与“is-a”问题相关，而组合与“has-a”问题相关。Python中的组合通常是通过多重继承实现的，因此“组合与继承”的问题有点奇怪。该语言提倡Duck typing风格，因此“has-a”问题被认为更具惯用性。在

当我们谈论ORMs时，还有其他含义：继承是如何在幕后实现的？一些实现将对象数据分布在多个表上并执行SQL联接，而其他实现将使用单个表并执行SQL联合。所以你不应该浪费精力去想。第一个原因是它对您是透明的，这是使用ORM时的全部要点。其次，您缺乏判断哪一个更适合您的特定用例的知识（您必须深入研究SQL和几个RDBMs的具体实现细节，以了解其中涉及的性能影响）。在

我的建议是使用您喜欢的编程风格来实现它，信任ORM实现的选择，并让DBA关注性能。在