为什么 Oracle 表/列/索引名限制为30个字符？

我可以理解，许多年前会有这种限制，但现在肯定可以很容易地增加这种限制。我们有对象的命名约定，但是总有一种情况出现在我们达到这个限制的地方——特别是在命名外键时。

有没有人真正知道为什么这个不是更大的尺寸-或者它在11g 中更大？

显然，答案是它会破坏当前没有防御性编码的脚本。我说这是一件非常令人担忧的事情，Oracle 正在努力成为 的数据库，当然这是你必须不断改进的东西，否则你的产品会死一千次。

每当我在公司内部看到这种反对意见时，我认为是时候咬紧牙关解决问题了。如果人们运行的脚本在升级 Oracle 版本时没有检查或维护，那么就让他们承担这种选择的后果。为他们提供一个兼容性标志，大小上升到4000，然后节省我浪费的时间，当我创建的对象不得不不断计数到30检查名称是“确定”。

91824 次浏览
小开
最佳答案

我相信这是 ANSI 的标准。

编辑:

事实上，我认为这是 SQL-92标准。

该标准的后续版本似乎可以选择性地支持128个字符的名称，但是 Oracle 还不支持这一点(或者说只支持30个字符的名称)。嗯。)

在此页搜寻「 F391，长标识符」 ... http://stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/ap_standard_sql001.htm

(找裁判)

小开

除了牛仔式的观点，即它来自 SQL 标准(历史上，我怀疑 Oracle 的决定导致了 SQL 标准，因为 Oracle 早于 SQL 标准化) ，我敢打赌，不愿意允许更长的标识符的很大一部分原因是意识到，有数以百万计的 DBA 与数以百万计的自定义脚本，都假定标识符是30个字符长。允许每一行代码

  l_table_name VARCHAR2(30);
BEGIN
SELECT table_name
INTO l_table_name
FROM dba_tables
WHERE ...

因为 DBA 15年前在剧本中使用了 VARCHAR2(30)而不是 DBA_TABLES.TABLE_NAME%TYPE而突然中断，这会引起大规模的反抗。我敢打赌，单是 Oracle 就有成千上万的地方多年来在各种软件包和组件中完成了这类工作。改进所有现有的代码以支持更长的标识符将是一个巨大的项目，它几乎肯定会在开发人员时间、质量保证时间和新引入的 bug 方面产生比产生效益更多的 方式成本。

小开

在 SQLERRM 中报告违反约束的情况，限制为255个字符，大多数客户机使用这些字符来使错误可见。我怀疑大幅增加约束名称的允许大小会显著影响报告违反情况的能力(特别是在通过几层 PL/SQL 代码冒出一个违反约束情况的情况下)。

小开

好吧，限制是存在的。

但是你真的需要超过30个字符来命名一个表/索引/列吗？

在编写查询时，由于这个限制，我仍然觉得一些列/表名很烦人。如果限制更高，我可能会遇到需要如下查询的表:

select unique_identifier_column,
time_when_the_user_remembered_to_change_the_row_in_the_receipt_table,
foreign_key_to_the_ap_invoice_distributions_history_table_related_to_the_all_rows_table
from ap_invoices_really_really_all_all_rows_present_in_this_ebs_table.

我很抱歉说了这么大的一句话: P

小开

我相信30个字符的标识符长度来自 COBOL，它在20世纪50年代后期被标准化了。由于 COBOL 程序是 SQL 的主要用户(在此之前是 SEQUEL (在此之前是 QUEL)) ，因此对于标识符长度来说，这个数字似乎是合理的。

小开

鉴于标识符长度限制的实际必要性，良好的设计限制了实际名称的长度，以避免在名称相互组合并使用前缀和后缀时出现问题。

例如，命名外键约束的约定

FK_<table1>_<table2>

将表名限制在13个字符或更少; 大多数数据库将需要更多的前缀和后缀，从而进一步限制表名的长度。

小开

所有这些“约束”都是对70年代处理器架构所施加的限制的反应。 从那时起，时间处理器已经发展到这样的程度: 这些限制不再是必要的; 它们只是被遗留下来了。 然而，对于 RDBMS 的作者来说，更改它们是一件大事。由于这些长度限制会影响下游的所有东西，所以无论如何也不能适应较长的过程名称可能会破坏许多其他东西，例如执行报告、数据字典等等。 我需要一个主要的重写的 Oracle RDBMS。

小开

以上所有的评论都是正确的，但是您需要记住较长名称的性能成本。在20世纪90年代早期，当 Informix 建立了巨大的广告牌“ Informix 比 Oracle 更快!”在 Oracle 总部旁边的101路由上，Informix 只允许表名短于18个字符！原因很明显——字面形式的表名(即作为实际名称而不是‘ t138577321’或类似的名称)存储在数据字典中。较长的名称等于较大的数据字典，并且由于每次查询需要硬解析时都会读取数据字典，因此较大的数据字典等于较差的性能..。

小开

这个问题的直接答案是 Oracle 风格继承了旧的思想，其中30个看起来很多，而且更多的会增加从典型数据库的实际内存中解除字典缓存的风险。

相比之下，ODBC 命名空间来自一个非常不同的地方，在这里，通过解析 Excel 表中的表并自动构建从表表标题中获取列名的数据库表，可以快速提取数据集。这样的思考导致您允许包含嵌入式回车的标识符，当然还有特殊字符和混合大小写。它是一个合理的抽象，因为它模拟了当今数据分析师的思维方式。

别管 SQL92了，ODBC 遵从性对当今的通用数据库真的很重要，其他供应商比 Oracle 更好地解决了这个问题。例如 Teradata，虽然很多人并不认为它是一个普遍的参与者，但它可以满足两个名称空间的需求，前者有30个字符的限制，后者是一个完整的 ODBC 实现，其中奇怪的长标识符可以满足需求。

即使是在传统的大型数据库领域，30个字符通常也是一个问题，因为名称要保持有意义、一致和令人难忘。一旦你开始设计具有角色命名继承的专门结构，你就会开始缩写，一致性很快就会消失，因为例如，作为表名或列名呈现的相同根标识符在一种情况下需要进一步的缩写，而在另一种情况下则不需要。如果大量的真实用户被邀请到这些层，结果是非常糟糕的可用性，幸运的是，对于任何老化的数据库，现在的主要驱动力是通过对象层和 BI 工具将用户从数据库中分离出来。

这就把数据库层留给了 DBA 和数据架构师团队，他们可能不会那么烦恼。制定缩写方案似乎仍然是一项终身的工作。

Oracle 没有解决这个旧的限制可能主要反映了这样一个事实: 当它不能直接移植使用较长标识符构建的数据库设计时，它并没有因为竞争而失去太多业务。

小开

我在谷歌上查找并发现了这个问题，但同时也发现，从 Oracle 12c Release2(12.2)开始，这个问题就不再是严格意义上的问题了。 (https://oracle-base.com/articles/12c/long-identifiers-12cr2)

在某种程度上，每个 DBA 或开发人员都会遇到这样的问题: 对象名称的30个字符的限制造成了问题。从 SQLServer 或 MySQL 到 Oracle 进行迁移项目时，这种限制可能非常痛苦。在 Oracle Database 12cR2中，大多数标识符的最大长度现在是128个字符。

根据(http://blog.dbi-services.com/oracle-12cr2-long-identifiers/) ，这是12.2中的一个新特性。根据那篇文章，12.1仍然被限制在30个字符以内。

编辑: 这里有一个指向 Oracle 官方文档的链接，解释了这个变化

从 Oracle Database 12c Release2(12.2)开始，大多数类型的数据库对象的标识符名称的最大长度已增加到128字节。


提交答案