Oracleのテーブル/列/インデックス名が30文字に制限されているのはなぜですか？
私は何年も前にこの種の制限があったことを理解できますが、今日では確かにこの制限を簡単に増やすことができます。オブジェクトには命名規則がありますが、特に外部キーの命名では、この制限に達した場所が常に判明します。
なぜこれが大きいサイズではないのか、または11gでは大きいのですか？
どうやらその答えは、現在、防御的にコーディングされていないスクリプトを破壊するということです。私はそれが非常に心配なことだと言います、Oracleはtheデータベースになろうとしています.
社内でこの種の異議を見るときはいつでも、弾丸を噛んで整理する時だと思います。 Oracleバージョンをアップグレードするときにチェックもメンテナンスも行わないスクリプトを実行している場合は、その選択の結果に苦しむようにしてください。互換性フラグを提供し、サイズを最大4000にし、名前が「OK」であることを確認するために常に30にカウントしなければならないオブジェクトを作成するときに無駄な時間を節約します。
ANSI標準だと思います。
編集：
実際、これはSQL-92標準だと思います。
標準の以降のバージョンでは、オプションで128文字の名前を許可するように見えますが、Oracleはまだこれをサポートしていません（または、30文字を許可する限り、部分的にサポートしています）。
このページで「F391、長い識別子」を検索してください... http://stanford.edu/dept/itss/docs/Oracle/10g/server.101/b10759/ap_standard_sql001.htm
（参照を探しています）
SQL標準から派生しているというcagcowboyのポイントに加えて（歴史的に、OracleがSQLの標準化に先駆けて以来、Oracleの決定はSQL標準につながったと思われます）、より長い識別子を許可することへの抵抗の大部分は識別子が30文字の長さであると想定している数百万のカスタムスクリプトを持つ数百万のDBAがいるという認識。次のようなコードのすべての行を許可する
l_table_name VARCHAR2(30);
BEGIN
SELECT table_name
INTO l_table_name
FROM dba_tables
WHERE ...
15年前のDBAは、スクリプトでDBA_TABLES.TABLE_NAME%TYPEではなくVARCHAR2（30）を使用していたため、突然の中断が発生し、大規模な反乱が発生しました。オラクルだけでも、この種のことがさまざまなパッケージやコンポーネントで長年行われている場所が何千もあると思います。より長い識別子をサポートするために既存のすべてのコードを改良することは、ほとんど確実にway開発者時間、QA時間、および新たに導入されたバグで、利益を生み出すよりも多くのコストを生み出す途方もないプロジェクトです。
私はこれを調べていて、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文字に制限されていました。
編集：これは、変更を説明するオラクルの公式ドキュメントへのリンクです。 （ 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でさえ、引用符の有無にかかわらず、2つの名前空間に対応しています。前者は30文字の制限があり、後者は完全なODBC実装です奇妙な長い識別子が用意されています。
従来の大規模なデータベースの分野でも、名前が意味のある、一貫性のある、記憶に残る30文字が問題になることがよくあります。役割名の継承を使用して特殊な構造の設計を開始すると、略語の省略を開始します。たとえば、テーブル名または列名としてレンダリングされた同じルート識別子は、ある場合にはさらなる略語を必要とし、他の場合は。かなりの数の実際のユーザーがそのようなレイヤーに招待された場合、その結果は非常に使い勝手が悪くなります。
これにより、データベースレイヤーはDBAとデータアーキテクトチームに委ねられます。略語スキームを作成することは、今でも人生の仕事です。
Oracleがこの古い制限に対処しなかったことは、おそらく、より長い識別子を使用して構築されたデータベース設計を直接移植できない場合に、（まだ）多くのビジネスを競合に負けていないという事実を反映しています。
上記のコメントはすべて正しいですが、長い名前のパフォーマンスコストに留意する必要があります。 1990年代初頭、Informixが巨大な看板「Informix Faster Than Oracle！」を設置したときOracle本社の隣のルート101では、Informixはテーブル名を18文字未満しか許可していませんでした！理由は明らかです-リテラル形式のテーブル名（つまり、「t138577321」またはそのようなものではなく実際の名前として）は、データディクショナリに格納されます。長い名前はより大きなデータディクショナリに等しく、クエリがハード解析を必要とするたびにデータディクショナリが読み取られるため、より大きなデータディクショナリはパフォーマンスの低下に等しくなります...