在我的一个数据库类分配中，我写道，我特意没有为我的NUMBER列分配长度作为代理键，因为它会不必要地限制能够存储在表中的记录数，并且因为它有在NUMBER（n）和NUMBER之间，性能或物理存储没有区别。
我的教授回信说，这在技术上是可行的，但对于大型数据库来说“不切实际”，而且现实生活中的大多数DBA都不会这样做。
就物理存储或性能而言，NUMBER（n）和NUMBER之间没有任何区别，因此没有理由为基于NUMBER的代理键列指定长度。为什么这位教授认为单独使用NUMBER会“不切实际”？
答案 0 :(得分：1)
根据我的经验，现实生活中的大多数生产DBA可能会按照您的建议进行操作，并将关键列声明为NUMBER而不是NUMBER（n）。
值得教授教授在他或她看来是什么使得这种方法不切实际。我可以想到几种可能性
假设您正在使用数据建模工具来设计模式，合理的工具将确保密钥的数据类型在表中被定义为主键的表中是相同的，并且在子表中这是一把外键。如果指定主键的长度，则强制键生成没有长度限制的外键将是不切实际的。当然，与此相反的是，您只需将主键和外键列声明为NUMBER。
DBA往往非常挑剔（我的意思是这是一种恭维）。他们喜欢看到所有组织“就是这样”。将长度限定符添加到字段（无论是NUMBER还是VARCHAR2）用作隐式约束，以确保不会存储不正确的数据。理想情况下，您可以知道何时设计一个表，您将在表的生命周期中插入行数的合理上限（即，如果您的PERSON表最终超过100亿行，则可能会出现问题严重错误）。将长度约束应用于数字列向DBA演示您已完成此类分析。
然而，今天，至少在数字列方面实际上不太可能实际发生，因为它更符合瀑布规划方法，通常涉及那种详细的设计讨论，而且因为人们较少关注传统上同时进行的增长分析。如果您在20或30年前设计数据库模式，那么在DBA上线和未来几年内逐个分析每个表的预计大小并不常见。今天，在磁盘上花费更多资金而不是花时间预先进行这种分析更具成本效益。
答案 1 :(得分：0)
从可读性和自我文档的角度来看，将列中存储的内容限制为预期的数字可能会更好。我同意我不知道它是如何不切实际的
number（n）是一个编辑 - 将数字限制为n个数字。
如果您存储号码＆＃39; 55＆＃39;它会占用相同的空格（2） 就像在数字中那样（38）。
所需存储空间=实际存储数量的函数。
答案 2 :(得分：0)
留给我自己的设备我会在oracle而不是NUMBER上将代理主键声明为NUMBER（38）。并且可能是检查约束以使密钥＆gt; 0.主要用作外部系统的文档，说明他们在专栏中可以期待的内容以及他们需要能够处理的内容。
理论上，在构建正在读取代理主键的应用程序时，查看NUMBER表示需要处理完整floating point range of number，而NUMBER（38）表示应用程序需要处理最多38位数的整数。
如果我在一个所有前端将使用32位整数作为代理键的环境中工作，我会将其定义为具有适当检查约束的数字（10）。