我很好奇 pk 以及它们是如何工作的。Django 自动将所有模型的主键设置为自动递增整数字段,但这通常是效率方面的最佳选择吗?
在哪些情况下将 pk 保留为递增整数比以某种方式创建自定义整数更有害?人们通常使用的自定义pk是什么?
编辑:最后一个问题。对于我之前的大部分项目,我都在 URL 中公开使用主键作为获取参数,例如:website.com/1234/ 其中 1234 是查询模型的 pk 'id'。这被认为是糟糕的设计还是这样做的共性?
谢谢!
我很好奇 pk 以及它们是如何工作的。Django 自动将所有模型的主键设置为自动递增整数字段,但这通常是效率方面的最佳选择吗?
在哪些情况下将 pk 保留为递增整数比以某种方式创建自定义整数更有害?人们通常使用的自定义pk是什么?
编辑:最后一个问题。对于我之前的大部分项目,我都在 URL 中公开使用主键作为获取参数,例如:website.com/1234/ 其中 1234 是查询模型的 pk 'id'。这被认为是糟糕的设计还是这样做的共性?
谢谢!
主键只是表中数据的一种特殊类型的索引。主键的一个约束是它必须是唯一的。当您使用 where 子句中的主键执行查找时,该数据的检索速度非常快。
如果您的查询永远不会使用主键执行查找或将其数据与基于主键的另一个表连接,那么拥有自动递增的主键并没有多大用处。在这种情况下,它只是一个浪费的索引,您最好使用表中其他列的主键(如果您可以满足唯一约束)。如果使用自动递增的 pkey 没有意义,并且您也不能拥有唯一索引,那么只需创建没有 pkey 的表,并确保在获取、更新或删除时始终使用最有效的索引单条记录。
我想不出任何理由将 pkey 保留为自动递增整数弊大于利,如果从未使用过,只会浪费空间并变得无关紧要。 正如评论中所指出的,当 pkey 是访问数据所需的唯一信息时,顺序主键可能会暴露信息或使您容易受到某些社会工程攻击。
如果您想使用复合索引作为主键,您可以使用自定义主键。另一个实例可能是跟踪所有具有唯一序列号的项目的表。在这种情况下,您可以将序列号用作 pkey 而不是自动递增的 ID,因为序列号也是唯一的,并且可能会在大多数查找或搜索中使用。