关于数据库建模的建议，OneToOne 与多个相关表
Advice on database modeling, OneToOne with multiple related tables
我正在寻找关于对我的数据库进行建模的最佳方法的建议
假设我有三个实体：会议、习惯和任务。每个都有自己独特的模式，但是，我希望所有 3 个都有一些共同点。
它们应该都包含日历信息，例如 start_date、end_date、recurrence_pattern 等...
有几种方法可以解决这个问题：
- 将这些字段添加到每个实体
- 创建一个事件实体并在每个其他实体上有一个 foreign_key 字段，指向相关的事件
- 创建一个事件实体并在事件上有 3 个 foreign_key 字段（每个其他实体一个）。在任何给定时间，这些字段中只有 1 个有值，另外 2 个为 null
- 创建一个包含 2 个字段 related_type 和 related_id 的事件实体。对于任何给定的行，related_type 值将是“会议”、“习惯”或“任务”之一，而 related_id 将是该实体类型的实际 ID。
我将有单独的 api 端点来访问会议、习惯和任务。
我需要 return 事件数据以及它们。
我还将有一个端点 return 所有事件。
我将需要 return 相关的实体数据以及每个事件。
选项 4 似乎是最灵活的，但不需要使用外键。
我不确定这是一个问题还是阻碍了性能。
我说它在我添加一个新实体的情况下很灵活，我们称之为“游戏”，事件模式已经能够处理这个。
创建新游戏时，我会创建一个新事件，并将 related_type 设置为“游戏”。
我认为事件端点可以加入 related_type 并且也几乎不需要更新。
此外，在我添加许多具有事件数据的新实体的情况下，这似乎比选项 3 更好。
对于这些实体中的每一个，都会将一个新列添加到事件中。
选项 1 和 2 可以正常工作，但是我不能只查询所有事件，我必须查询每个其他实体。
关于这种情况是否有任何最佳实践？还有其他方法吗？
最终性能比灵活性更重要。我宁愿更新代码也不愿牺牲性能。
我正在使用 django，也许有人对此有一些提示，但是，我真的在寻找有关数据库本身的最佳实践，而不是 api 实现。
我会保持简单并选择选项 1。将数据拆分为比正确规范化所需的 table 多的数据不会带来好处。
也许您会喜欢使用 PostgreSQL table 继承的想法。你可以有一个空的 table event，你的三个 table 继承自 table。这样，它们会自动拥有 event 中的所有列，但它们仍然是三个独立的 table。
我正在寻找关于对我的数据库进行建模的最佳方法的建议
假设我有三个实体：会议、习惯和任务。每个都有自己独特的模式，但是，我希望所有 3 个都有一些共同点。
它们应该都包含日历信息，例如 start_date、end_date、recurrence_pattern 等...
有几种方法可以解决这个问题：
- 将这些字段添加到每个实体
- 创建一个事件实体并在每个其他实体上有一个 foreign_key 字段，指向相关的事件
- 创建一个事件实体并在事件上有 3 个 foreign_key 字段（每个其他实体一个）。在任何给定时间，这些字段中只有 1 个有值，另外 2 个为 null
- 创建一个包含 2 个字段 related_type 和 related_id 的事件实体。对于任何给定的行，related_type 值将是“会议”、“习惯”或“任务”之一，而 related_id 将是该实体类型的实际 ID。
我将有单独的 api 端点来访问会议、习惯和任务。
我需要 return 事件数据以及它们。
我还将有一个端点 return 所有事件。
我将需要 return 相关的实体数据以及每个事件。
选项 4 似乎是最灵活的，但不需要使用外键。
我不确定这是一个问题还是阻碍了性能。
我说它在我添加一个新实体的情况下很灵活，我们称之为“游戏”，事件模式已经能够处理这个。
创建新游戏时，我会创建一个新事件，并将 related_type 设置为“游戏”。
我认为事件端点可以加入 related_type 并且也几乎不需要更新。
此外，在我添加许多具有事件数据的新实体的情况下，这似乎比选项 3 更好。
对于这些实体中的每一个，都会将一个新列添加到事件中。
选项 1 和 2 可以正常工作，但是我不能只查询所有事件，我必须查询每个其他实体。
关于这种情况是否有任何最佳实践？还有其他方法吗？
最终性能比灵活性更重要。我宁愿更新代码也不愿牺牲性能。
我正在使用 django，也许有人对此有一些提示，但是，我真的在寻找有关数据库本身的最佳实践，而不是 api 实现。
我会保持简单并选择选项 1。将数据拆分为比正确规范化所需的 table 多的数据不会带来好处。
也许您会喜欢使用 PostgreSQL table 继承的想法。你可以有一个空的 table event，你的三个 table 继承自 table。这样，它们会自动拥有 event 中的所有列，但它们仍然是三个独立的 table。