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

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模型，其中包含属性，

class VotesComponent(Base):
    votes      = relationship('Vote')
    vote_ups   = Column(Integer)
    vote_downs = Column(Integer)

Comment并与和模型建立多对一的关系Article。

通过深入研究 SQLAlchemy 文档，我后来发现可以通过使用连接表继承来实现类似的功能。乍一看，这似乎非常方便，因为避免了额外的间接级别（即可以引用 comment.votes 而不是 comment.votes_component.votes），但我以有限的理解看到的一个很大的缺点是，多重继承不是支持，而使用早期的方法，可以自由地向模型添加任意数量的“组件”。

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

编辑：我应该提到，我希望能够单独查询模型的“投票”部分，以便我可以多态地处理投票。

Answer 1

这是一个很好的问题，但这里有点偏离主题，因为邀请基于意见的答案的问题在 stackoverflow 上是不受欢迎的。也就是说，这是我个人的看法（我真的想避免引发一场口水战）。

所以，我的问题是，使用继承映射相对于组合有什么好处，什么时候更可取，为什么？

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

当我们谈论 ORM 时，还有其他含义：继承是如何在幕后实现的？一些实现将对象数据分布在多个表上并执行 SQL JOIN，其他实现将使用单个表并执行 SQL UNION。恕我直言，这不是你应该浪费精力思考的事情。第一个原因是它对您来说是透明的，这就是使用 ORM 的重点。其次，您缺乏判断哪一种更适合您的特定用例的知识（您必须深入研究 SQL 和几个 RDBM 的具体实现细节，以了解所涉及的性能影响）。

我的建议是使用您喜欢的编程风格来实现它，信任 ORM 实现的选择，并将性能问题交给 DBA。