数据库：什么设计指出两种可能性？

Question

我正在为新项目设计数据模型。

其中一项要求规定某些对象可以指向某个人或公司。

实现这一目标的最明智的方法是什么？

我想过一个表格链接＆＃34;演员＆＃34;像这样（用优秀的yUML.me BTW绘制）：

在actor表中，根据actor_type，person_id或company_id是其对应表格中的外键，或者是NULL。这样，当one_table想要检索有关actor的详细信息时，我首先检查actor_type字段并检索person_id或company_id。

它正在运作，但我正在寻找更好的设计。 Here is the link for editing the diagram

Answer 1

很难真正给出答案，但我有一些可能对你有用的笔记。

但他们真的只是一些笔记。

总的来说，这个数据模型似乎很好，因为已知。

• 演员类型不一定需要是另一个表。例如，它可能只是该表上的编码值。
• 正如其他评论中所指出的那样，如果演员只能指出这两件事，那么演员类型表在技术上并不是必需的 - 但是我可能仍然会使用它，因为它更容易维护并且更长时间可读代码/ sql /数据库的未来维护者的术语。即，即使机器不需要，表示类型的字段的存在也增加了代码/ sql和模型的人类可读性的价值。
• 考虑数据库的发展，有一点要考虑，你认为它总是只是个人/公司，或者将来可能会有不同的类型。如果将来可能是其他actor类型，那么现在值得考虑将actor_type和id分解为链接表是否有助于限制此表的模式的演变。

Answer 2

我建议你制作引用相同超类型（演员）的公司和人物子类型。请注意，您不需要单独的person_id，company_id，因为参与者必须是一个或另一个，并且不能同时存在。像这样：

Answer 3

这是类/子类的经典案例（或者，如果您更喜欢类型/子类型）。我建议你访问以下三个标签，查看标记的问题以及你可以在＆＃34下看到的标签维基;了解更多＆＃34;。

single-table-inheritance class-table-inheritance shared-primary-key

这可能会为您提供所需的所有答案。或者您可能更愿意在问题中添加一个或多个这些标记，以吸引更多答案。

注意：＆＃34;继承＆＃34;标签中使用的是这些技术允许您获得构建到实现继承的对象环境中的一些好处。