文章目录

软件工程的老师上课说数据库中的用户数据表的主键要用自增的user_id做主键,而不要用username做主键。

这让我产生了一些疑问。

首先,用户登录时提供的账号信息必然是自选的字符串username,而不是整数类型的自增主键user_id
我认为usernameuser_id其实都是具有唯一性约束的字段。因此username完全可以替代user_id的作用,所以user_id就显得没那么有必要了。
如果没有其他足够的理由(比如优化之类的,可能我还不知道这个理由)是不应该引进这么个“多余”的字段的。

带着这样的疑问,我询问了老师这么做的原因。

老师给出了这样的回答,节省存储
因为用户的主表只是存储用户的基本信息,其他用户表需要以用户主表的主键作为外键来存储信息。

这么说来,的确是这个样子的。
使用INTEGER UNSIGNED类型来存储user_id作为用户分表的外键,比起使用VARCHAR类型的username做外键,显然要节省存储的多。
毕竟前者只占用4个字节的存储,而后者占用username长度+1个字节的存储,显然不会有几个人的username会设置成3个字母以内嘛。
而且,数据越多,数据表越多,节省的存储也就越大。

理由很充分嘛。于是我继续问老师还有没有别的原因,他没再回答。

但是我觉得原因肯定不仅仅是这个,毕竟大部分应用和算法都是以空间换时间
user_id应该有某种效率上的优势才对,虽然我现在认为看起来反而使用user_id效率反而应该低些。

理由是:用户登录提供的是username,因此,如果用户主表是以user_id作为主键,那么应用需要通过登录用户提供的username在用户主表中查询出user_id,然后在用户分表中通过在用户主表查询出来的user_id来查询用户其他相关信息。
而如果直接采用username的话,不需要在用户主表做查询了,直接就可以拿着username在各种用户分表查各种用户信息。

当然,上面的理由其实都是我的一种猜测而已,正确的学习习惯是学习不能够想当然,因此,猜测归猜测,终归还是要验证的。

我只好找了一位已在工作中的前辈(外校的一个学长,帮助我解决了许多问题)询问这个问题。

在我与他的讨论中,他给出了如下的回答:

  1. 老师说的没错,确实是能够节省存储
  2. 通常实践中也确实是使用整数类型的user_id来做主键的
  3. 整数字段做主键更加易于分表
  4. 自增主键比起字符串做索引,效率更高(看,果然有效率的问题哈)
  5. username这个东西过于偏向业务,如果今后系统还需要允许邮箱登录,手机号登录呢?

以上的回答我认为第3,4,5点是非常重要的原因。
3,4的原因可以归结为在效率上和分表操作性上确实比用username做主键要好;
5则说明了对于那种扩展登录的业务,使用里面任何一种登录方式的字段作为主键都不太合适。

文章目录