为什么Oracle表/列/索引名称限制为30个字符？
我可以理解，多年前会有这种限制，但是现在肯定这个限制很容易增加。 我们有命名约定的对象，但总是有一个例子，我们碰到这个限制，特别是在命名外键。
有人真的知道为什么这不是一个更大的尺寸 – 或者是11g更大？
显然答案是，它会打破目前没有防守编码的脚本。 我说这是一件非常令人担忧的事情，甲骨文正在努力成为数据库，当然这是你必须不断提高的东西，否则你的产品就会死千裁员。
每当我看到这种反对意见的时候，我认为是时候咬紧牙关把它整理一下了。 如果人们在运行升级Oracle版本时没有检查或维护的脚本，那么让他们承受这种select的后果。 为他们提供一个兼容性标志，大小增加到4000，然后当我创build的对象必须不断计数到30来检查名称是'好'时，省去浪费的时间。
我相信这是ANSI的标准。
编辑：
其实，我认为这是SQL-92标准。
标准的更高版本似乎可以select允许128个字符的名称，但是Oracle还不支持这个（或者部分支持它，只要它允许30个字符就可以）。
在此页面中search“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会引起大规模的反抗。 我敢打赌，只有甲骨文有成千上万的地方，这些东西多年来在各种封装和组件中完成。 改造所有现有的代码来支持更长的标识符将是一个巨大的项目，几乎肯定会在开发者时间，QA时间和新引入的bug方面产生更多的成本，而不是产生收益。
我正在查找这个问题，并通过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的一个新function。 根据这个post，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）开始，大多数types的数据库对象的标识符名称的最大长度已增加到128个字节。
考虑到标识符长度限制的实际必要性，良好的devise限制了实际名称的长度，以避免当名称相互结合并带有前缀和后缀时达到最高限度。
例如，一个命名外键约束的约定
FK_<table1>_<table2>
将表名限制为13个字符或更less; 大多数数据库将需要更多的前缀和后缀，进一步限制表名的长度。
SQLERRM中限制为255个字符，并且大多数客户端使用它来使错误可见。 我怀疑，显着增加约束名称的大小会影响报告违规的能力（特别是通过几层PL / SQL代码冒出约束违规的情况下）。
我相信30个字符的标识符长度来自于20世纪50年代末被标准化的COBOL。 由于COBOL程序是SQL（以及之前的SEQUEL（以及之前的QUEL））的主要用户，所以对于标识符长度来说，这似乎是合理的数字。
所有这些“约束”都是由对来自70年代的处理器体系结构所施加的限制的回应所遗留的。 从那时起，处理器已经发展到不再需要这些限制的地步。 他们只剩下了。 但是，改变它们对于RDBMS的作者来说是一笔巨大的交易。 由于这些长度限制影响了下游的一切变化，所以容纳一个较长的程序名称可能并且可能会打破许多其他的东西，例如报告，数据字典等等等等。 我需要重新编写Oracle RDBMS。
这个问题的直接答案是，Oracle风格是从旧的想法中inheritance而来，其中30个看起来很多，而且更多的风险会增加从典型数据库的实际内存中拔出字典caching的风险。
相比之下，ODBC命名空间来自一个非常不同的地方，通过parsingExcel工作表中的一个表，快速提取数据集，并自动生成带有表格标题中列名的数据库表。 这样思考会导致您允许甚至包含embedded回车符的标识符，当然还有特殊字符和混合大小写。 这是一个明智的抽象，因为它模仿了今天的数据分析师的思维方式。
不要在意SQL92，这对于今天的通用数据库来说是非常重要的ODBC兼容性，其他厂商比Oracle更好地解决了这个问题。 即使Teradata也不例外，它是一个普遍的select，可以提供两个名称空间，无论是否带引号，前者有30个字符的限制，后者是一个完整的ODBC实现，其中奇怪的长标识符可以满足。
即使在传统的大型数据库领域，30个字符通常也是一个问题，名称要保持有意义，一致和令人难忘。 一旦开始devise具有angular色名称inheritance的专业化结构，您就开始缩写缩写，并且一致性很快就会消失，因为例如，呈现为表名或列名的相同根标识符在一种情况下需要进一步缩写，而另一种情况下则不需要。 如果大量的真实用户被邀请到这样的层上，结果是可用性非常差，幸运的是对于任何老化的数据库，现在的主要驱动器是通过对象层和BI工具将用户与数据库分开。
这将数据库层留给了DBA和数据架构师团队，他们可能不那么困扰。 看起来，制定缩略语scheme仍然是终身的工作。
甲骨文没有解决这个旧的限制，或许主要反映在它不能直接移植使用更长标识符构build的数据库devise的时候，它还没有在竞争中失去太多的业务。
以上所有的评论都是正确的，但是你需要记住长名字的性能成本。 在二十世纪九十年代初，Informixbuild立了巨大的广告牌“Informix比Oracle快！” 在Oracle总部旁边的路由101上，Informix允许表名只有18个字符以内！ 原因是显而易见的 – 以字面forms（即作为实际名称而不是“t138577321”或类似的东西）存储在数据字典中的表名称。 较长的名称等于较大的数据字典，并且由于数据字典在每次查询需要硬parsing时被读取，所以较大的数据字典等于较差的性能…
好的，限制存在….
但你真的需要超过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
