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

我可以理解，很多年前会有这种限制，但如今肯定可以轻松地增加此限制。我们有对象的命名约定，但是总有一种情况会达到这个极限，尤其是在命名外键时。

有人真的知道为什么它不是更大吗？还是11g更大？

显然，答案是它将破坏当前没有防御性编码的脚本。我说这是一个非常令人担忧的事情，甲骨文正在试图成为该数据库，想必这是什么样的，你必须不断提高的东西，否则你的产品会死一千削减死亡。

每当我在公司内部看到这种异议时，我认为是时候该硬着头皮整理一下。如果人们运行的脚本在升级Oracle版本时没有检查或维护，那么他们将遭受这种选择的后果。给他们提供一个兼容性标志，大小最大为4000，然后为我节省创建对象的浪费时间，这些对象必须不断地计数到30来检查名称是否为“ OK”。

我相信这是ANSI标准。

编辑：

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

该标准的更高版本似乎可以选择允许128个字符的名称，但是Oracle尚不支持此名称（或仅部分支持它，因为它允许30个字符。嗯。）

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

（寻找参考）

除了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脚本中的VARCHAR2（30）会引起大规模反抗。我敢打赌，多年来，仅Oracle就拥有成千上万种使用各种程序包和组件来完成此类工作的地方。改造所有现有的代码，以支持更长的标识符将是一个巨大的工程，几乎肯定会产生办法的开发时间更多的成本，质量保证时间，和新引进的错误比这将产生效益。

我一直在查找并通过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个字节。

考虑到标识符长度限制的实际必要性，良好的设计会限制实际名称的长度，以免在名称相互组合且带有前缀和后缀的情况下达到上限。

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

FK_<table1>_<table2> 

表格名称不得超过13个字符；大多数数据库将需要更多的前缀和后缀，从而进一步限制了表名的长度。

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

我相信30个字符的标识符长度来自于1950年代后期标准化的COBOL。由于COBOL程序是SQL的主要用户（在此之前是SEQUEL（在此之前是QUEL），因此在标识符长度上似乎是一个合理的数字。

所有这些“约束”都是对70年代处理器架构所施加的限制的回应。从那时起，处理器已发展到不再需要这些限制的程度。他们只剩下。但是，对于RDBMS的编写者来说，更改它们是一项大交易。由于这些长度限制会影响下游的所有变化，因此，为了适应这个问题，我们会说，更长的过程名称可能并且很可能会破坏很多其他内容，例如感知报告，数据字典等，等等。我需要对Oracle RDBMS进行重大重写。

这个问题的直接答案是，Oracle风格是从较早的想法继承而来的，在旧的想法中，似乎30年代很多，而更多的想法将增加从典型数据库的实际内存中取消字典高速缓存的风险。

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

不用担心SQL92，对于当今的通用数据库而言，真正重要的是ODBC遵从性，其他供应商比Oracle更好地解决了这一问题。例如，即使不是很多人都喜欢的Teradata，也可以满足两个命名空间的需要，带引号和不带引号，前者有30个字符的限制，后者是一个完整的ODBC实现，可满足奇怪的长标识符的需要。 。

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

这将数据库层留给了DBA和数据架构师团队，他们也许并不那么在意。看来，制定缩写方案仍然是终生的工作。

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

以上所有注释都是正确的，但是您需要记住长名称的性能成本。在1990年代初期，Informix设立了巨大的广告牌“ Informix比Oracle快！”。在Oracle总部旁边的101号路由上，Informix允许表名仅短于18个字符！原因很明显-表名以其原义形式（即实际名称而不是“ t138577321”或类似名称）存储在数据字典中。较长的名称等于较大的数据字典，并且由于每次查询需要进行硬解析时都会读取数据字典，因此较大的数据字典等于较差的性能...

好，限制存在。

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