database - 使用指定代理键的长度

Question

在我的一个数据库类作业中，我写道我特别没有为充当代理键的 NUMBER 列分配长度，因为它会不必要地限制能够存储在表中的记录数，并且因为有NUMBER(n) 和 NUMBER 在性能或物理存储方面几乎没有区别。

我的教授回信说，这在技术上是可行的，但对于大型数据库来说“不切实际”，现实生活中的大多数 DBA 都不会这样做。

就物理存储或性能而言，NUMBER(n) 和 NUMBER 之间没有任何区别，因此没有理由为基于 NUMBER 的代理键列指定长度。为什么这位教授认为单独使用 NUMBER 是“不切实际的”？

Answer 1

根据我的经验，现实生活中的大多数生产 DBA 可能会按照您的建议去做，并将键列声明为 NUMBER 而不是 NUMBER(n)。

有必要问问教授，在他或她看来，是什么让这种方法不切实际。我能想到的有几种可能性

假设您正在使用数据建模工具来设计您的模式，一个合理的工具将确保键的数据类型在定义为主键的表中和在定义为主键的子表中相同它是一个外键。如果您指定主键的长度，强制该键生成没有长度限制的外键是不切实际的。当然，与此相反的是，您可以将主键列和外键列都声明为 NUMBER。

DBA 往往非常挑剔(我的意思是这是一种恭维)。他们喜欢看到一切都井然有序。向字段添加长度限定符(无论它是 NUMBER 还是 VARCHAR2)作为隐式约束，确保不存储不正确的数据。理想情况下，当你设计一个表时，你会知道在表的生命周期内插入的行数的合理上限(即，如果你的 PERSON 表最终有超过 100 亿行，可能会出现严重错误)。将长度约束应用于数字列可以向 DBA 证明您已经完成了此类分析。

然而，今天，至少在数字列方面，这不太可能实际发生，因为它更符合瀑布规划方法，通常会涉及那种详细的设计讨论，而且因为人们更少关注传统上会同时进行的增长分析。如果您在 20 或 30 年前设计数据库架构，那么向 DBA 提供每个表在上线时和 future 几年的预计大小的逐表分割并不少见。今天，在磁盘上花更多的钱比花时间预先进行这种分析更具成本效益。