2

在我的 Web 应用程序中，用户可以定义文档并给它们一个唯一的名称来标识该文档，以及一个人类用来引用该文档的友好名称。以下面的表模式为例：

|   id   |    name        |   friendly_name   |
-----------------------------------------------
|    2   |    invoice-2   |   Invoice 2       |

在此示例中，我使用id列作为主键，这是一个自动递增的数字。由于文档 ( name) 已经有一个自然 ID，我也可以这样做：

|    name        |   friendly_name   |
--------------------------------------
|    invoice-2   |   Invoice 2       |

在本例中，name是文档的主键。我们已经消除了该id字段，因为它本质上只是 的副本，因为表格中的每个文档无论如何name都必须具有唯一性。name

这也意味着当我从外键关系中引用文档时，我必须调用它document_name而不是document_id.

这方面的最佳做法是什么？从理论上讲，我完全可以将 aVARCHAR用作主键，但它是否有任何缺点，例如性能开销？

4

2 回答 2

3

关于这个话题有两种思想流派。

有些人坚信使用“自然键”作为实体表的主键是可取的，因为它比代理键具有显着的优势。

其他人则认为“代理”密钥可以提供“自然”密钥可能无法提供的一些理想属性。

让我们总结一下主键的一些最重要和最理想的属性：

  • 最小 - 尽可能少的属性数
  • 简单 - 本机数据类型，理想情况下是单列
  • available - 创建实体时，该值将始终可用
  • 唯一 - 绝对没有重复，没有两行将具有相同的值
  • 匿名 -不携带隐藏的“有意义”信息
  • 不可变 - 一旦分配，将永远不会被修改

（还有一些其他的属性可以列出来，但是其中一些属性可以从上面的属性中派生出来（不为空，可以索引等）

我将关于“自然”和“代理”键作为“最佳”主键的两种思想分为两个阵营：

1）那些因早先决定选择自然密钥作为主密钥而被严重烧毁的人，以及

2）那些还没有被那个决定烧死的人。

于 2014-09-28T21:24:50.290 回答
0

当然可以。

create table sometbl(
`name` varchar(250) NOT NULL PRIMARY KEY,
`friendly_name` varchar(400)
);

访问整数或 varchar（除非它太长）键的时间没有任何区别。即使有，它也不会是您的主要瓶颈。只要将一列声明为键，mysql就可以非常快速地访问它。

自增整数不能为主键。它只是行的序列号。当您查看实物时，您会发现它没有任何序列号。所以主键应该基于那些真实的属性。

于 2014-09-28T19:27:43.280 回答