【问题标题】:Is correct have a table in a 1 to 1 relationship with a FK that is also a PK?是否有一个与 FK 也是 PK 的 1 对 1 关系的表?
【发布时间】:2012-08-17 12:03:40
【问题描述】:

我有一张名为 Player 的桌子

  • 玩家 ID (PK)
  • 更多栏目

我想创建另一个与名为 PlayerExtraInfo 的播放器具有 1 对 1 关系的表以包含一些列。所以我有几个选择:

  1. 不创建新表,而是将 PlayerExtraInfo 列添加到 Player 表

  2. 创建 PlayerExtraInfo 表并在 Player 表中有一个 FK。

    播放器

    • 玩家 ID (PK)
    • 更多栏目
    • PlayerExtraInfoID (FK)

    PlayerExtraInfo表格

    • PlayerExtraInfo (PK)
    • 更多栏目
  3. 相反:PlayerExtraInfo 包含一个 FK 到 Player 表。为了确保关系保持 1 对 1,我添加了一个唯一约束。

    播放器

    • 玩家 ID (PK)
    • 更多栏目

    PlayerExtraInfo表格

    • PlayerExtraInfo (PK)
    • 更多栏目
    • PlayerID(FK,唯一)
  4. 类似于选项 3,但将 PK 和 FK 合二为一。在这种情况下,我的外键也成为主键:

    播放器

    • 玩家 ID (PK)
    • 更多栏目

    PlayerExtraInfo表格

    • 玩家 ID(PK、FK)
    • 更多栏目

我知道选项 1、2 是正确的,但由于性能问题,我是选项 3 或 4 的选项。考虑到这 3 和 4 选项,我对选项 4 产生了一些疑问: 所以我的问题是:

  • 选项 3 和 4 是否正确?
  • 选项 4 会破坏任何正常形式吗?
  • 还有其他我没有想到的选择吗?

【问题讨论】:

    标签: sql database-design foreign-keys foreign-key-relationship


    【解决方案1】:

    当用另一个表扩展一个表时,使用主键作为外键绝对没问题(并且也推荐)。

    【讨论】:

      【解决方案2】:

      虽然选项 2、3、4 是正确的,但我认为选项 1 会提供最佳性能。即使使用聚集索引,额外的连接也是额外的连接。此外,外键会降低目标表的性能(我承认大量外键会降低性能,而不是单个)。

      除了扩展表只有一小部分主表记录的情况,或者您希望在不同分区上的 2 个表的情况下,我想不出有理由将该表拆分为和平表。

      【讨论】:

      • 虽然这是真的,但它通常是过早的优化。另一方面,如果不总是需要表 2 中的数据,选项 4 可能是更快的解决方案。
      • 不是真正的优化,是我扩展表格时的起点。此外,选项 4 可以比 1 更快的唯一时间是在插入/更新行时(条件仅在表 1 上完成工作)。选择时,我认为 4 没有理由比 1 更快。即使您选择通常在 1 中的数据也不行。(除非您执行 select * from table 之类的操作)
      • 例如,如果您的表中有 BLOB,即使 BLOB 本身不是查询列的一部分,查询也会变慢。另一个原因可能是类继承的映射。请参阅我对 Diego 帖子的评论。
      • 1.我们谈论的是泛型,而不是细节。我对 SQL 到应用程序而不是对 SQL 的应用程序感兴趣。如果 ORM 正在设计您的数据库,那完全是另一回事。因此,您不会将自己的问题放在如何做到这一点上,因为您对此无话可说。 2. 我们不是在谈论宽桌。宽表使用列集,它们是无类型的 XML,因此它们本身增加了一组全新的复杂性。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2018-02-18
      • 1970-01-01
      • 2011-01-22
      • 2021-12-08
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多