数据库可伸缩性：表大小或查询数量哪个更重要？

问题描述

| 我将以简化的StackOverflow系统为例。 尽管限制了某些功能，但可能会将问题和答案保存在同一表格中：

(Django-esque pseudo-code)

QA table:
    parent = ForeignKey(self)
    category = ForeignKey(Category)
    title = CharField()
    description = TextField()

然后，要获得ID为1的问答题，将对

id==1

或

parent==1

进行SQL SELECT。失败的原因是Answers不使用

tags

和

title

字段 当然，替代方案将是两个表：

Questions:
    category = ForeignKey(Category)
    title = CharField()
    description = TextField()

Answers:
    parent = ForeignKey(Questions)
    description = TextField()

这将需要两个查询才能获得“问答”。 本能说前者是一个可怕的想法，但我不确定为什么。 哪个更快，更可扩展？     

解决方法

        要直接回答您的问题，您的直觉是正确的。将实体（问题和答案）混合到一个表中几乎总是一个坏主意。从逻辑上讲，它们是2个独立的实体，从物理上讲，它们应保持分开。 您的第二个解决方案是正确的。使用索引和外键通过问题ID链接2个表将使您可以选择任何问题的所有答案。除了将来对必须使用该结构的任何人更容易理解之外，这将更快并且可以更好地扩展。     ,        我认为这里没有一个好的答案。以我的拙见，最好的答案是取决于情况。例如，如果将问题和答案放在两个单独的表中，则您将自己局限于该模型。例如，您不能具有某种层次结构中的子答案或子问题。可能不错，但不一定适合您的环境。 我个人尝试查看情况和数据。如果相对于答案我必须存储关于一个问题的不同数据（或者如果出于两个不同的目的我必须使用同一列），那么我将创建两个表。如果数据相同并且将始终相同，则将其存储在一个表中。 但是，除了数据库模式的有限视图之外，还需要考虑更大的局面。例如，什么是最适合您的存储引擎？什么是最适合您的硬件？要备份吗？要存档吗？性能和可伸缩性将取决于许多因素。这是开始讨论的好地方，但这只是冰山一角。