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

Question

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

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

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

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

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

Answer 1

cag*_*boy 71

我相信这是ANSI标准.

编辑:

实际上,我认为这是SQL-92标准.

该标准的更高版本似乎可选择允许128个字符名称,但Oracle尚不支持此功能(或者只支持30个字符,因此Oracle部分支持它.嗯.)

在此页面上搜索"F391,Long identifiers"... http://stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/ap_standard_sql001.htm

(寻找参考)

事实上,Oracle粉丝们没有看到30多个字符标识符的用处,这令人不安."让你的名字有意义/描述性,使用下划线代替驼峰,并保持在30个字符以下".这将*永远*超过30个字符.Amirite？更像是缩写缩写,当没有名称有意义时,花一整天时间阅读/更新文档. (44认同)
部分合规.真是笑话."我们的螺丝部分符合公制标准,但它们不是公制标准." (20认同)
SQL-92标准在这里http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt,但如果您阅读"17.1 SQL项描述符区域的描述"部分,它会显示名称和模式必须至少允许128个字符. (7认同)
我没有详细阅读F391规范,但我假设(可能不正确)"长标识符"意味着标识符长度从30增加到128.所以说你通过允许30个字符"部分"支持这个有点厚脸皮.你不支持新标准,你仍然支持旧标准(尽管是新标准的25%)这有意义吗？!!？ (5认同)

Answer 2

Jus*_*ave 45

除了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 ...

Run Code Online (Sandbox Code Playgroud)

突然之间因为DBA 15年前使用VARCHAR2(30)而不是DBA_TABLES.TABLE_NAME%TYPE脚本会导致大规模的反抗.我敢打赌单凭甲骨文有数千个地方,这些年来已经在各种包装和组件中完成了这种事情.改造所有现有的代码,以支持更长的标识符将是一个巨大的工程,几乎肯定会产生办法的开发时间更多的成本,质量保证时间,和新引进的错误比这将产生效益.

当然是时候增加一对并增加它 - 添加一个标志,以便DBA可以将其细化回到30.这样的遗留问题应该总是面对并排序,否则你最终会削弱整个代码库,人们只会移动到其他东西 (43认同)
+1这几乎可以肯定是甲骨文的许多传统设计瘫痪之一. (13认同)
他们无法将它作为一个新功能大肆宣传,或者......他们会花费大量时间来扩展限制,然后宣布"你现在可以使用超过30个字符的名字!".他们是笑柄. (10认同)
如果你还在使用15岁的剧本,**有些东西是非常错误的**.此外,修复它们将是一次性成本(可能还有一些用于持续维护),而开发人员将继续浪费时间不必要地无限制作可怕的缩写名称.@skaffman就我而言,他们已经是一个笑柄,而不是*修复它(以及其他一些在现代时代可悲的设计决策,比如没有布尔或自动递增的类型),就我而言. (8认同)
不仅数百万行DBA编写代码,而且毫无疑问也有大量的oracle内部代码.这个话题出现在与史蒂文·费尔斯坦的会谈中,他说他不认为他们会改变它. (6认同)
这是真的.Oracle可能还有很长的路要走.是时候继续研究基于现代技术的解决方案了.甲骨文:"我们几十年来一直是值得信赖的名字,我们没有改变!" (3认同)

Answer 3

Kan*_*uri 11

我正在查找这个并通过谷歌发现这个问题,但也发现从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

Lor*_*tti 6

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

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

FK_<table1>_<table2>

Run Code Online (Sandbox Code Playgroud)

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

Answer 5

Gar*_*ers 5

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

它不是一个表,而是客户端软件如何实际从数据库中获取错误. (2认同)

Answer 6

Mac*_*Mac 5

所有这些“约束”都是对来自 70 年代的处理器架构施加的限制的响应。从那时起，处理器已经发展到不再需要这些限制的地步。他们只是剩下的。然而，改变它们对于 RDBMS 的作者来说是一件大事。由于这些长度限制会影响下游的所有内容，因此无法适应说更长的过程名称可能并且可能会破坏许多其他内容，例如异常报告、数据字典等，等等。我需要对 Oracle RDBMS 进行重大重写。

归档时间：	16 年，1 月前
查看次数：	77380 次
最近记录：	8 年，10 月前