Question

假设我正在与Steam用户合作，每个用户都有一个独特的SteamID。我是否仍需要单独的id列作为主键，还是可以使用SteamID？即这就足够了（使用Flask-SQLAlchemy）：

class User(db.Model):
    steamid = db.Column(db.String(20), primary_key=True, unique=True)
    name = db.Column(db.String(120))
    # more stuff

或者我是否仍应包含Flask-SQLAlchemy's examples中所见的唯一id：

class User(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    steamid = db.Column(db.String(20), unique=True)
    name = db.Column(db.String(120))
    # more stuff

如果是这样，为什么？

Answer 1

反对它的主要论据是性能，整数主键通常更快查询和使用。

这主要是一个偏好问题，如果steamid的索引更有意义并且更容易推理我会选择它，因为性能差异不会很大。

Answer 2

虽然ID值的数值对于系统进行排序和定位要快一些，但差异不大可能是显而易见的，甚至是不可测量的。

问题是，您不会说出 steam 是什么或它在您的系统中扮演的角色。但显然，它与每个用户之间存在1-1的关系。那么为什么不在User表中将其命名为 ID ，并根据需要将其别名为 UserID 或 SteamID ，具体取决于哪个在上下文中更有意义用户恰好在当时。

使用代理键时，我倾向于将其称为ID。简短，明确，简洁。在查看表格的定义时，它说，＆＃34;我是这张表的代理键。＆＃34;在同一查询中使用多个表的相同字段时，确实没有混淆。事实上，它有助于澄清：

select User.ID, Item.ID, Entry.ID, etc.
from ....

但是，查询会建立结果集的上下文。别名有助于显示上下文：

select User.ID as ManagerID, Item.ID OfficeOD, Entry.ID LaptopID, etc.
from ....

在另一个表中将其用作FK时，该表中的名称也会在该表建立的上下文中显示其用法。如果多个字段是同一个表的FK，这将特别方便：

table Accounts: 
  ID         the surrogate key to this table...duh!
  OwnerID    references User.ID
  AdminID    references User.ID
  VerifiedBy references User.ID

或者

table Accounts: 
  ID         the surrogate key to this table...duh!
  SteamID    references User.ID
  AdminID    references User.ID
  VerifiedBy references User.ID

Answer 3

对于大多数情况，SteamID应该足够了。如果ID很接近并且差异是ID中的空格或那种类型的东西，则可能会有问题。使用uniqueId是最好的方式。

如果我已经拥有一个唯一的密钥，是否有理由拥有一个单独的id主键？

3 个答案: