Question

我正在制作一张桌子

移动型号信息

+-------------+-----------------+------+-----+---------+----------------+
| Field       | Type            | Null | Key | Default | Extra          |
+-------------+-----------------+------+-----+---------+----------------+
| ID          | int(5) unsigned | NO   | PRI | NULL    | auto_increment |
| linktospecs | varchar(255)    | YES  |     | NULL    |                |
| name        | varchar(30)     | NO   | UNI | NULL    |                |
| company     | varchar(20)     | NO   |     | NULL    |                |
+-------------+-----------------+------+-----+---------+----------------+
4 rows in set (0.01 sec)

在此表中，来自任何手机制造商的每部手机只会出现一次，并带有其他信息，如制造商的名称和其规格的官方链接。这就是我现在能想到的全部。

我想要的是，因为name列本身就是唯一的（两行相同的移动模型会很愚蠢），我希望能够使用它进行索引，因为在我的应用程序中，当用户搜索移动名称时，我会使用name列来检索此表中的所有其他列。

但是在很多例子中，我看到人们使用一个额外的简单ID列，自动递增以保持它作为一个简单的主键。所以，我的问题是，我是否需要保留ID列，或者唯一name列是否足以使用此表？我是数据库和SQL的新手。

Answer 1

将ID列作为主键总是一个好主意，因为它永远不会改变。如果您需要更改电话名称，并且名称是主键，则之前对该电话的任何引用都将立即停止工作，因为主键值不再存在。另一方面，如果每个ID都有唯一的ID，则可以更改名称而不影响ID，所有以前的引用都将保持有效。

两家不同的公司也可能推出同名手机，在这种情况下，如果名称是您的主键，那么您只能在其中一个上存储信息。

Answer 2

主键意味着它将是一个聚集索引 - 您将比name列更多地搜索您的id列，因此搜索应该在非群集上进行微小改进指数。 - https://stackoverflow.com/a/3543719/2724079

Answer 3

我更喜欢ID，因为名称可能与诺基亚500和HTC 500相匹配。您不能在型号名称中添加公司名称。在这种情况下，您可能会获得多个。最好使用＆＃34; ID＆＃34;作为这种情况的关键。

如果您不想使用ID作为附加列，请使用公司和名称的组合作为密钥。

Answer 4

在我看来，使用ID列会更好，如果你想要添加一些功能，包括外键（其他表中出现的表的主键）概念，那么使用{ {1}}可能只是你的任务，也可能是你在不同方面的努力（如果您需要更改电话名称，并且名称是主键，则之前对该电话的任何引用都将立即停止工作，因为主键值不再存在）

我应该在哪个列上创建主键？

4 个答案: