【问题标题】:surrogate keys vs compound keys代理键与复合键
【发布时间】:2011-12-13 18:58:44
【问题描述】:

对数据库架构相当陌生(计划使用 SQLite)。话虽如此,我正在考虑使用代理键,因为数据库当前包含一个复合键(3 列),它显示在我的大多数表中。我有几个表,其中包含 3 列的唯一键和包含一些信息的列;我也有一张表包含 3 列唯一键和相同的 3 列作为外键(许多父母)。将所有这些表合并到一个表中似乎没有意义,因为会有很多空字段。

如果我选择其中一个,会掉坑吗?通常认为哪一种更方便编程?

提前谢谢你。

【问题讨论】:

  • "3 columns for the unique key" -- 相同的 3 列?这听起来像是糟糕的架构设计。将表合并在一起。 NULLs 比凌乱的LEFT JOINs 问题更小。

标签: sql database sqlite database-schema


【解决方案1】:

每种技术都有优点和缺点。

通常,如果您只需要引用单个代理键列,则编写 SQL 语句和 JOIN 会更容易。它还大大减少了数据库的大小。

另一方面,使用代理键时,您经常发现自己必须向 JOIN 中添加至少一个额外的表才能检索代理键中的信息。

代理键的另外两个优点:

  1. 许多框架要求使用整数主键字段。

  2. 如果您将记录绑定到任何类型的用户界面控件(例如网页上的输入),则将单个值附加到控件以进行识别比编码和编码要容易得多。解码多列。

【讨论】:

  • 为什么在使用自增 PK 和代理键作为候选键时要添加另一个表?我已经放弃了 /not/ 有一个单一的“PK”——尽管 SQLite always 提供了一个 ROWID 又名“int PK”——但发现信息仍然可以在模型中编码适当的约束,以另一个[候选/覆盖]索引的“费用”为代价,就减少插入时的碎片而言,该索引可能“更便宜”。如果候选索引对表进行非规范化,那么它从不成为 [surrogate] PK 的有效候选...
  • 包含产品、子组件、组件的材料清单。在 Sub-Assembly 中,(ProductID, AssemblyName) 是唯一的。如果将其用作 Component 中的 PK 和 FK,则可以通过仅使用 Component 的产品找到 Component 使用情况。相反,如果您使用代理整数主键,则必须 JOIN Sub-Assembly(或使用子查询技术)来获取该信息。
  • 感谢您的简洁回答。代理现在确实更有吸引力,因为我的大多数查询可能不会基于键(而是基于属性,例如分数)。虽然,数据库的构建和编辑似乎需要更多的工作,查询可能需要更长的时间。
猜你喜欢
  • 1970-01-01
  • 2014-07-12
  • 2015-09-28
  • 1970-01-01
  • 2010-12-10
  • 2015-08-05
  • 1970-01-01
  • 2013-12-01
  • 1970-01-01
相关资源
最近更新 更多