相关疑难解决方法(0)

当我可以使用其他人作为关键字段时,为什么要创建 ID 列?

可能的重复:
为什么使用 int 作为查找表的主键?

到目前为止,我习惯于为每个表创建一个 ID 列,它的实用性使我不必考虑有关主键理论的决策。

我大学的教授建议全班从一个或多个字段制作主键,这些字段构成关于每一列的一个唯一信息。是的,我想养成使用自然键而不是代理键的习惯。维基百科上列出了代理键的优缺点,我严格推荐这篇文章

我见过人们对所有内容都使用整数 ID 字段,但没有人评判这种方法,因为

  • 它“看起来”高效
  • 使用了一个数字字段,它看起来更酷,因为它在内存中每行的大小

我开始认为额外的 ID 字段只是创建冗余数据而没有实际好处。那么当我可以使用其他列作为关键字段时,为什么还要创建 ID 列呢?

  • 如果您的 ID 字段是 32 位,则它已经相当于 4 个 ASCII 字符。
  • 如果您的 Id 字段是64 位整数,则它是8 个字符的字符串,因此它实际上并没有节省那么多内存(这里暗示的是用于比较的内存。额外的 id 列已经添加到使用的内存中(HDD 和 RAM) ) )
  • 额外的 ID 字段会使您的索引成本加倍,因为您还将索引一个可以用作主键的唯一字段。
  • 如果您需要可以用作关键字段的数据,则进行额外的联接,例如,如果您在一篇博客文章中存储了唯一的用户 ID,以显示作者姓名,则进行联接查询,如果您的密钥字段是作者的名字,你不需要加入,因为你将相关数据存储在博客帖子表中。具有有意义数据的外键字段减少了子查询或连接的需要

在此处输入图片说明

  • 创建一个额外的 id 字段“添加”到内存负载,它不是唯一字符串字段的替换,您不是用整数替换 char-varchar 字段,而是添加一个额外的列并创建额外的数据流。所以任何数据存储的比较都应该在“string”和“int+string”之间进行。添加整数 id 字段不节省空间。

另一方面

  • 分配从用户输入中获取价值的主键数据可能会出现问题,因为人们可能会输入错误的社会安全号码,并且由于独特的政策,想要注册的实际人员将无法注册。这可以通过在原始号码上添加一个或多个额外数字来规避。

额外资源:

  1. 自然vc代理键的比较

我从阅读文章中得出的结论是,我应该尽可能使用自然键,而不是每次都跳过考虑自然键并使用代理键,好像这是一个标准。

mysql sql-server primary-key uniqueidentifier surrogate-key

54
推荐指数
4
解决办法
4万
查看次数