数据库关系:不使用PK？
数据库关系:不使用PK？
提问于 2014-07-20 22:27:43
假设我有以下表格：
Foo
- id
- code (Unique)
- name
- descption
Bar
- id
- foo_codeBar.foo_code指向Foo.code有缺点吗？通常，我看到引用的是if (例如，会有一个指向Bar.foo_id的Foo.id)，但在我的例子中，如果它实际上指向的不是自动递增的PK，那么它就会简单得多。
我很好奇，这是否是糟糕的设计，或是否会有一个在性能上的惩罚。
回答 3
Stack Overflow用户
回答已采纳
发布于 2014-07-20 22:34:02
不，没有坏处。可能取决于可读性，取决于列的实名。但是，请注意，如果Foo.code是唯一的，那么它实际上是一个主键。只需确保它也是索引和您是黄金。如果Foo.code实际上是唯一的，那么您甚至可以摆脱Foo.id并节省一些空间。
Stack Overflow用户
发布于 2014-07-20 22:40:59
如果您真的使用另一个键作为主键，那么您需要保持自动递增id的原因是什么呢？
默认情况下，表将在主键上排序。默认情况下按code排序可能更有意义。而且，这需要更多的数据存储，更新速度也会慢一些，因为这两个索引都必须更新。对于许多应用程序来说，性能差异对实际影响很小，但如果不使用自动增量id，我就想不出有什么理由保留它。
代理主键确实有它们的用途，但是如果您已经有了一个要用作主键的唯一列，那么使用该唯一列作为您的PK完全不是一个好的设计。
Stack Overflow用户
发布于 2014-07-21 17:54:46
取决于您打算如何查询：
- 如果您经常需要确定与给定
Bar相关联的Bar，那么直接在FK中引用它可以有效地将从Foo迁移到Bar，从而允许您在不使用连接的情况下进行操作。 - 但是，如果您还需要获取double-lookup或
Foo.descption，那么连接是不可避免的，引用Foo.id可以避免支付Foo.id价格由MySQL/InnoDB集群引起的。
话虽如此，您可能可以使用移除代理项键 Foo.id，从而消除整个困境。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/24855505
复制相关文章
相似问题
腾讯云开发者
