Question

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

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

显然答案是它会破坏当前没有防御编码的脚本。我说这是一个非常令人担忧的事情，甲骨文正试图成为数据库，当然这是你必须不断改进的事情，否则你的产品将会死于一千次削减。< / p>

每当我在内部看到这种反对意见时，我认为是时候咬紧牙关并将其解决了。如果人们正在运行在升级Oracle版本时不检查或维护的脚本，那么让他们承受该选择的后果。为他们提供一个兼容性标志，大小达到4000，然后节省我浪费的时间，当我创建必须经常数到30的对象来检查名称是否'OK'。

Answer 1

我认为这是ANSI标准。

修改

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

该标准的更高版本似乎可选择允许128个字符名称，但Oracle尚不支持此功能（或者只支持30个字符的部分支持。嗯。）

在此页面上搜索“F391，长标识符”... http://stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/ap_standard_sql001.htm

（寻找参考资料）

Answer 2

除了cagcowboy的观点，它源于SQL标准（从历史上看，我怀疑Oracle的决定导致SQL标准，因为Oracle早于SQL的标准化），我敢打赌，很大一部分不情愿允许更长时间标识符来自于数百万个具有数百万个自定义脚本的DBA的认识，这些脚本都假设标识符长度为30个字符。允许每行代码类似

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

突然中断因为15年前DBA在脚本中使用VARCHAR2（30）而不是DBA_TABLES.TABLE_NAME%TYPE会引起大规模的反抗。我敢打赌单凭甲骨文有数千个地方，这些年来已经在各种包装和组件中完成了这种事情。对所有现有代码进行改造以支持更长的标识符将是一个巨大的项目，几乎肯定会在开发人员时间，QA时间和新引入的错误中产生方式更多的成本，而不是产生好处。

Answer 3

我正在查找并通过Google发现此问题，但也发现从Oracle 12c第2版（12.2）开始，情况已不再严格。（https://oracle-base.com/articles/12c/long-identifiers-12cr2）

在某些时候，每个DBA或开发人员都会遇到对象名称的30个字符限制导致问题的程度。从SQL Server或MySQL迁移到Oracle时，此限制可能非常痛苦。在Oracle Database 12cR2中，大多数标识符的最大长度现在为128个字符。

根据（http://blog.dbi-services.com/oracle-12cr2-long-identifiers/），这是12.2中的新功能。根据该帖子，12.1仍然限制在30个字符之内。

编辑：这是一个指向官方Oracle文档的链接，解释了这一变化。（https://docs.oracle.com/cloud/latest/exadataexpress-cloud/CSDBF/longer-identifier-names.htm#CSDBF-GUID-F4CA155F-5A37-4705-8443-0A8C9E3F875C）

从Oracle Database 12c第2版（12.2）开始，大多数类型的数据库对象的标识符名称的最大长度已增加到128个字节。

Answer 4

鉴于标识符长度限制的实际必要性，良好的设计限制了实际名称的长度，以避免在名称彼此组合并具有前缀和后缀时达到上限。

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

FK_<table1>_<table2>

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

Answer 5

在SQLERRM中报告约束违规，限制为255个字符，并且大多数客户端使用它来使错误可见。我怀疑增加约束名称的允许大小会显着影响报告违规的能力（特别是在通过几层PL / SQL代码冒出约束违规的情况下）。

Answer 6

我认为30个字符的标识符长度来自于20世纪50年代后期标准化的COBOL。由于COBOL程序是SQL的主要用户（以及之前的SEQUEL（以及之前的QUEL）），这对于标识符长度来说似乎是一个合理的数字。

Answer 7

所有这些＆＃39;约束＆＃39;留在对70年代来自处理器架构所施加的限制的回应。从那时起，处理器已经发展到不再需要这些限制的程度;他们只是遗留下来。但是，更改它们对于RDBMS的编写者来说是一笔巨大的交易。由于这些长度限制会影响下游的所有内容，因此无法容易地说明更长的过程名称可以并且可能会破坏许多其他内容，例如异常报告，数据字典等，等等。我需要重新编写Oracle RDBMS。

Answer 8

这个问题的直接答案是，Oracle风格继承自旧观念，其中30种似乎很多，而且更多会增加在典型数据库中从实际内存中取消字典缓存的风险。

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

不要介意SQL92，它的ODBC兼容性对于今天的通用数据库非常重要，其他供应商已经比Oracle更好地解决了这个问题。例如，即使Teradata，许多人都不认为它是普遍存在的玩家，它可以满足两个名称空间，有或没有引号，前者有30个字符串限制，后者是一个完整的ODBC实现，其中奇怪的长标识符可以满足

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

这将数据库层留给了DBA和数据架构师团队，他们可能并不那么烦恼。制定缩写方案似乎仍然是生活中的工作，似乎。

甲骨文没有解决这个旧的限制或许主要反映的是，当它不能直接移植使用较长标识符构建的数据库设计时，它还没有（但）在竞争中失去太多业务。

Answer 9

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

Answer 10

好的，存在限制....

但你真的需要超过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

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

10 个答案: