我正在设计一个包含课程和工作的网站。
我有一个工作表和课程表，每个工作或课程都由一个“机构”提供，它可以是机构（提供课程）或公司（提供工作）。我正在这两个选项之间做出决定：
选项 1：使用“机构”表，机构和公司都有 body_type 列。
选项2：使用单独的“机构”和“公司”表。
我的主要问题是还有一个帖子表，其中显示了所有课程和工作的广告。因此，如果我选择第一个选项，我只需要为每个帖子添加一个 body_id 作为记录，而如果我选择第二个选项，我需要在显示帖子时在某处有一个额外的连接。
哪个选项最好？还是有替代设计？
不要在 SQL 语法和“额外连接”方面考虑太多，多从模型、实体、属性和关系方面考虑。
在最高级别，模型的中心实体是 Post。帖子的属性是什么？
这些属性中的每一个对于该帖子都是唯一的，因此应该直接在帖子表中，或者不是并且应该在相关的表中；一个明显的例子是“谁发布了它”——这应该只是一个 PostedBy 字段，其 ID 与另一个表的海报/正文实体相关联。（注意：您的海报实体不一定是您的身体实体......）
您的海报/正文实体有自己的属性，这些属性对于每个海报/正文都是唯一的，或者再次，应该在它们自己的某个规范化实体中。
职位和课程帖子有很大不同吗？也许您应该考虑包含特定工作和课程数据的 CoursePosts 和 JobPosts 子表，然后将它们加入您的 Posts 表。
关键是让你的模型处于这样一种状态，即所有实体属性和关系在它们所在的位置都是有意义的。正确建模您的实际实体将防止性能和逻辑问题。
对于您的具体问题，如果您的身体在属性（姓名、联系信息等）方面通常相同，那么您希望将它们放在同一个表中。如果它们有很大不同，那么它们可能应该在不同的表中。如果它们有很大的不同，并且你的工作和课程也有很大的不同，那么一定要考虑为 JobPosts 和 CoursePosts 创建两个完全不同的数据模型，然后简单地将它们链接到 Posts 的一些超集表中。但是正如您所知道的，从面向对象的角度来看，如果您的 Posts 没有任何共同点，但可能只有一个唯一的密钥标识符和一些管理元数据，您甚至可能会问为什么要在应用程序中混合这两个实体。
解析层次结构时，通常有 3 个选项：
当你杀死父母时，我明白你在谈论的问题。基本上，您不知道必须在哪个表上创建外键。因此，除非您还创建了一个帖子层次结构，其中您有一个与机构相关的帖子和一个与公司相关的单独帖子表（可怕的解决方案！），这是不行的。您也可以在设计本身之外解决这个问题，在每个帖子中添加元数据，说明他们应该加入哪个表（这不是一个好的选择，因为您的架构不会是自我文档，并且数据将确定如何加入表......这是错误的易于）。
所以我会放弃杀死父母。如果不同表之间没有太多不同的字段，杀死孩子会很好。此外，您应该记住，这种方法不利于解决孩子既可以是机构也可以是公司的问题，但似乎并非如此。杀死孩子也是最有效的一种。
您尚未评估的第三个选项是同时保留两种方法。这样，您可以保留一个包含主体之间共享值的虚拟表，并且每个主体都有这个“抽象”表的 FK（如果您知道我的意思）。这通常是效率最低的方式，但很可能是最灵活的方式。通过这种方式，您可以轻松处理两种类型的主体，以及仅属于“主体”类型但不是公司或机构本身的主体（如果这甚至可能或将来可能）。您应该注意，为了将帖子加入机构，您应该始终引用父表，然后将父表与子表一起加入。
这个问题也可能对您有用：