【问题标题】:One table column for many fk tables?许多 fk 表的一个表列?
【发布时间】:2011-07-30 15:56:39
【问题描述】:

这种情况的最佳解决方案/做法是什么? 我有一个表,可以引用多个表(对象)?

这是一个表格 UserCalendar 的示例。这是一个用户保存他的事件的表,但系统也从后面插入到这个表中。用户执行一些服务,这些服务具有截止日期,并且这些服务也插入到此表中。问题是没有像 UserEvent 表这样的表。用户应将此日历中的所有事件保存为描述。我应该尽可能简单。

我可以设计这两种方式。

1)

用户日历
用户日历 ID |用户名 |说明 |对象类型 |对象标识

使用此选项,我不必对这些表进行 FK。我只能更改 ObjectType(通知、服务、日历)并将该表的 id 用作 ObjectId。在事件的情况下,将没有这样的表,这将是空字段。 我们称之为伪 FK 列。

2) 或者我可以按照理论上的说法为每个 FK 使用多个表。

用户日历
用户日历 ID |用户名 |说明

用户事件
UserCalendarId |EventId

用户服务
UserCalendarId|ServiceId

用户通知
用户日历 ID |通知 ID
...

对于每个系统事件或属于特定类型的任何其他自定义事件,此外部关系表可以是 n 个数字

第一个解决方案是快速实施。

【问题讨论】:

    标签: database database-design foreign-key-relationship database-normalization database-table


    【解决方案1】:

    我更喜欢将您的两种设计混合在一起的第三种解决方案:

    用户日历
    用户日历 ID |用户名 |说明

    用户日历属性
    用户日历 ID |对象类型 |对象标识

    通过这种方式,您可以根据需要随意向日历条目添加任意数量的附加引用(例如事件通知),并且您在 UserCalendar 表和任何其他表。

    如果将 FK 放入您的主 UserCalendar 表中是否有意义,这还取决于您必须多久访问一次附加数据(事件、服务等)。 p>

    我建议更多地关注灵活性而不是性能,尽管您会稍微增加架构的复杂性。与性能问题相比,功能需求发生变化的可能性更大。

    【讨论】:

      猜你喜欢
      • 2018-03-02
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2022-08-19
      • 1970-01-01
      • 2020-03-04
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多