Oracleのテーブル/列/インデックス名が30文字に制限されているのはなぜですか？

何年も前にこのような制限があったことは理解できますが、今日では確かにこの制限を簡単に増やすことができます。オブジェクトには命名規則がありますが、特に外部キーの命名では、この制限に達した場合に必ず発生する場合があります。

これがそれほど大きくない理由を誰かが実際に知っていますか？それとも11gでもっと大きいのですか？

どうやら答えは、防御的にコーディングされていない現在のスクリプトを壊すということです。これは非常に心配なことだと私は言います、Oracleはデータベースいます、確かにこれはあなたが絶えず改善しなければならない種類のことです。

社内でこの種の異議を目にするときはいつでも、弾丸を噛んで整理する時がきたと思います。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

（参照を探しています）

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 DBA_TABLES.TABLE_NAME%TYPEがスクリプトではなくVARCHAR2（30）を使用していたため、突然中断しました。Oracleだけでも、この種のことがさまざまなパッケージやコンポーネントで何年にもわたって行われている何千もの場所があることに賭けたいと思います。長い識別子をサポートするためのコードを既存のほぼ確実に生成する驚異的なプロジェクトであろうと、すべての改造方法、それが利益を生成するよりも、より多くの開発者の時間のコスト、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で報告されます。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文字が問題になることがよくあります。ロール名付き継承を使用して特殊化構造の設計を開始すると、略語の省略を開始し、すぐに一貫性が失われます。たとえば、同じルート識別子がテーブル名または列名としてレンダリングされる場合、ある省略形でさらに省略形が必要になり、他の省略形では不要になるためです。 。かなりの数の実際のユーザーがそのようなレイヤーに招待されると、その結果は使い勝手が非常に悪くなります。幸いなことに、古くなったデータベースの主な目的は、オブジェクトレイヤーとBIツールを介してユーザーをデータベースから分離することです。

これにより、データベース層はDBAとデータアーキテクトチームに委ねられます。略語体系を練ることはまだ人生の仕事だと思われます。

Oracleがこの古い制限に対処していないことは、長い識別子を使用して構築されたデータベース設計を直接移植できない場合に、（まだ）競争で多くのビジネスを失っていないという事実を反映している可能性があります。

上記のコメントはすべて正しいですが、長い名前のパフォーマンスコストを覚えておく必要があります。1990年代初頭、Informixが巨大な看板「Oracleよりも速いInformix！」を設置したとき。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