Varchar与代理主键的编号（不是自然键）

Question

您认为代理主键，数字或varchar的更好选择是什么？在我们的例子中，我们使用varchar2（15），所以不是一个非常大的列？

我不会重新打开关于自然和代理键使用的线程。 我们使用自动生成的主键列（也就是代理键）和用于业务键的用户键（也称为自然键）。我们不担心编写SQL必须加入许多表。 在主键中使用Varchar，我们可以使用前缀，后跟序列生成的数字转换为字符串。这允许基于该前缀值进行分区。

谢谢。 rimetnac

Answer 1

使用varchar2类型主键时可能遇到的一个威胁是nls_comp = linguistic由于自动内部varchar2-column-predicates，Oracle优化器将突然停止使用主键列的索引查找修改。而且我相信在某些情况下它也可能会停止进行分区修剪。当然，它可以通过编程方式修复，但它仍然是项目计划之上的一些工作。

第二个威胁是可能不正确的查询成本算法。我不记得它是多么不正确，你必须查找，例如乔纳森刘易斯＆＃39; ＆＃34;基于成本的Oracle基础知识＆＃34;预约自己，阅读相关章节，并对正在使用的Oracle版本进行自己的研究。

Answer 2

在Oracle中，VARCHAR值需要的空间大约是相等NUMBER值的两倍。这就是为什么VARCHAR主键意味着双倍大小的主键索引，更糟糕的索引搜索，更糟糕的缓冲区缓存利用率等等。我怀疑它是否是好的设计，特别是如果数据足够大以进行分区。

Answer 3

您正在使用您描述的设计造成不必要的问题。首先，您有一个唯一标识每个元组的自然键。但是您已选择使用代理键作为主键。到目前为止这很好。现在，您将引入一个未命名的属性，将元组分隔为逻辑分组。那也没关系。但是你为什么要把它与PK结合起来呢？那是什么获得的？通过将此属性分开，可以同样执行所需的分组（并且在许多方面更好）。

将这个属性与PK结合起来，可以说它失去了它的身份。这就像将每个学生的StudentID与大学数据库中专业的名称相结合。按照专业分组有多种原因，但现在没有特定的“主要”字段，而是“Major_SID”汞合金。一个显而易见的问题是切换专业。更新“主要”字段很容易。仅更新连接字符串的“主要”部分而保持其他部分不变更加困难。

这些额外的问题并非不可克服，如果收益更大，这些问题也是值得的。这种方法是否提供了这些压倒一切的好处？它是否提供任何好处？

减去这些好处，我的建议是将分组属性分开。这也将使代理键对元组的内容保持匿名。除了保持数字，这比文本更容易排序。

Answer 4

如果varchar没有唯一的自然键，请使用autoincrement int。