Por que os nomes de tabela / coluna / índice do Oracle são limitados a 30 caracteres?

Eu posso entender que há muitos anos atrás haveria esse tipo de limitação, mas hoje em dia certamente esse limite poderia ser facilmente aumentado. Temos convenções de nomenclatura para objetos, mas sempre existe um caso em que atingimos esse limite - especialmente na nomeação de chaves estrangeiras.

Alguém realmente sabe por que esse tamanho não é maior - ou é maior em 11g?

Aparentemente, a resposta é que ele quebrará os scripts atualmente que não são codificados defensivamente. Eu digo que é uma coisa muito preocupante, a Oracle está tentando ser o banco de dados, certamente esse é o tipo de coisa que você deve melhorar constantemente, caso contrário, seu produto morrerá com a morte de mil cortes.

Sempre que vejo esse tipo de objeção internamente, acho que é hora de morder a bala e resolvê-la. Se as pessoas estiverem executando scripts que não verificam ou mantêm quando atualizam as versões do Oracle, deixe-as sofrer as consequências dessa escolha. Forneça a eles um sinalizador de compatibilidade, até o tamanho de 4000, e economize o tempo perdido quando estou criando objetos, que precisam contar constantemente até 30 para verificar se o nome está 'OK'.

Eu acredito que é o padrão ANSI.

EDITAR:

Na verdade, acho que é o padrão SQL-92.

Uma versão posterior do padrão parece permitir opcionalmente 128 nomes de caracteres, mas a Oracle ainda não suporta isso (ou tem suporte parcial para ele, na medida em que permite 30 caracteres. Hmmm.)

Procure por "F391, identificadores longos" nesta página ... http://stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/ap_standard_sql001.htm

(À procura de uma ref)

Além do argumento de cagcowboy de que deriva do padrão SQL (historicamente, eu suspeito que a decisão da Oracle leve ao padrão SQL, já que a Oracle antecedeu a padronização do SQL), eu apostaria que grande parte da relutância em permitir identificadores mais longos vem de a percepção de que existem milhões de DBAs com milhões de scripts personalizados que assumem que os identificadores têm 30 caracteres. Permitindo que cada linha de código seja algo como

  l_table_name VARCHAR2(30);
BEGIN
  SELECT table_name
    INTO l_table_name
    FROM dba_tables
   WHERE ...

de repente quebrar porque o DBA, há 15 anos, usou o VARCHAR2 (30), e não DBA_TABLES.TABLE_NAME%TYPEno script, causaria revolta em massa. Eu apostaria que somente a Oracle tem milhares de lugares onde esse tipo de coisa foi feito ao longo dos anos em vários pacotes e componentes. A atualização de todo esse código existente para oferecer suporte a identificadores mais longos seria um projeto tremendo que certamente geraria muito mais custos em tempo de desenvolvedor, tempo de controle de qualidade e erros recém-introduzidos do que em benefícios.

Eu estava pesquisando isso e encontrei essa pergunta pelo Google, mas também descobri que, a partir do Oracle 12c Release 2 (12.2), esse não é mais o caso estritamente. ( https://oracle-base.com/articles/12c/long-identifiers-12cr2 )

Em algum momento, todo DBA ou desenvolvedor alcançará um ponto em que o limite de 30 caracteres para nomes de objetos causou um problema. Esse limite pode ser extremamente doloroso ao executar projetos de migração do SQL Server ou MySQL para Oracle. No Oracle Database 12cR2, o comprimento máximo da maioria dos identificadores agora é de 128 caracteres.

Este é um novo recurso da 12.2, de acordo com ( http://blog.dbi-services.com/oracle-12cr2-long-identifiers/ ). Segundo esse post, 12.1 ainda estava limitado a 30 caracteres.

Edit: Aqui está um link para a documentação oficial do Oracle que explica a alteração. ( https://docs.oracle.com/cloud/latest/exadataexpress-cloud/CSDBF/longer-identifier-names.htm#CSDBF-GUID-F4CA155F-5A37-4705-8443-0A8C9E3F875C )

A partir do Oracle Database 12c Release 2 (12.2), o comprimento máximo dos nomes de identificadores para a maioria dos tipos de objetos de banco de dados foi aumentado para 128 bytes.

Dada a necessidade prática de limites de comprimento do identificador, um bom design restringe o tamanho dos nomes reais para evitar atingir o teto quando os nomes são combinados entre si e com prefixos e sufixos.

Por exemplo, uma convenção de nomear restrições de chave estrangeira

FK_<table1>_<table2> 

limita os nomes das tabelas a 13 caracteres ou menos; a maioria dos bancos de dados precisará de mais prefixos e sufixos, limitando ainda mais o tamanho dos nomes das tabelas.

As violações de restrição são relatadas no SQLERRM, limitado a 255 caracteres e usado pela maioria dos clientes para tornar os erros visíveis. Suspeito que aumentar o tamanho permitido dos nomes de restrições impactaria significativamente a capacidade de relatar as violações (especialmente quando uma violação de restrição foi detectada através de algumas camadas de código PL / SQL).

Eu acredito que o comprimento do identificador de 30 caracteres vem do COBOL, que foi padronizado no final da década de 1950. Como os programas COBOL eram o principal usuário do SQL (e SEQUEL antes disso (e QUEL antes disso)), isso deve ter parecido um número razoável para o comprimento do identificador.

Todas essas 'restrições' são deixadas sob as respostas às limitações impostas pelas arquiteturas de processadores que vêm dos anos 70. Desde então, os processadores evoluíram a tal ponto que essas limitações não são mais necessárias; eles são apenas sobrando. No entanto, alterá-los é um grande negócio para os escritores do RDBMS. Como esses limites de comprimento afetam tudo a jusante, alterando-o sempre que necessário, digamos que um nome de procedimento mais longo possa e provavelmente irá quebrar muitas outras coisas, como relatórios de exceções, dicionário de dados, etc., e assim por diante. Eu exigiria uma grande reescrita do Oracle RDBMS.

A resposta direta à pergunta é que o estilo Oracle é herdado de idéias mais antigas, nas quais 30 pareciam muito, e muito mais teria aumentado o risco de desvincular o cache do dicionário da memória real em bancos de dados típicos.

Por outro lado, o espaço para nome ODBC vem de um local muito diferente, onde os conjuntos de dados são extraídos rapidamente, analisando uma tabela em uma planilha do Excel e construindo automaticamente tabelas de banco de dados com nomes de colunas extraídos dos cabeçalhos das tabelas. Pensar assim leva a permitir identificadores que até contêm retornos de carro incorporados e, é claro, caracteres especiais e letras maiúsculas e minúsculas. É uma abstração sensata porque modela a maneira como os analistas de dados de hoje pensam.

Não importa o SQL92, é a conformidade com o ODBC que realmente importa para o banco de dados universal de hoje, e outros fornecedores resolveram isso melhor do que o Oracle. Até o Teradata, por exemplo, que não é visto por muitos como um player abrangente, atende a DOIS namespaces, com e sem as aspas, o primeiro com um limite de 30 caracteres, o segundo uma implementação completa do ODBC, na qual são usados ​​identificadores longos e estranhos .

Mesmo na arena tradicional de grandes bancos de dados, 30 caracteres geralmente são um problema em que os nomes devem permanecer significativos, consistentes e memoráveis. Depois de começar a projetar estruturas especializadas com herança com nome de função, você começa a abreviar abreviações e a consistência acaba logo, porque, por exemplo, o mesmo identificador raiz processado como um nome de tabela ou nome de coluna precisará, em um caso, de abreviação adicional e, no outro, não . Se usuários reais em números significativos são convidados para essas camadas, as consequências são uma usabilidade muito ruim e, felizmente, para qualquer banco de dados antigo, a principal unidade agora é separar o usuário do banco de dados por meio de camadas de objetos e ferramentas de BI.

Isso deixa a camada do banco de dados para as equipes do DBA e do arquiteto de dados, que talvez não sejam tão incomodadas. A elaboração de esquemas de abreviação ainda é um trabalho para toda a vida, ao que parece.

O fato de a Oracle não ter abordado essa limitação antiga talvez reflita principalmente no fato de que ainda não está perdendo muitos negócios para a concorrência quando não pode portar diretamente projetos de banco de dados criados usando identificadores mais longos.

Todos os comentários acima estão corretos, MAS você precisa ter em mente o custo de desempenho de nomes mais longos. No início dos anos 90, quando o Informix montou um enorme outdoor "Informix mais rápido que a Oracle!" na rota 101 ao lado da sede da Oracle, o Informix permitia nomes de tabelas com menos de 18 caracteres! O motivo é óbvio - os nomes das tabelas em sua forma literal (ou seja, como nomes reais em vez de 't138577321' ou algo parecido) são armazenados no Dicionário de Dados. Nomes mais longos equivalem a um Dicionário de dados maior e, como o Dicionário de dados é lido sempre que uma consulta exige uma análise rígida, um dicionário de dados maior é igual a um desempenho ruim ...

ok, a limitação existe ....

mas você realmente precisa de mais de 30 caracteres para nomear uma tabela / índice / coluna?

ao escrever consultas, com essa limitação AINDA acho alguns nomes de colunas / tabelas irritantes. Se o limite fosse maior, eu poderia encontrar tabelas que exigiam uma consulta como:

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.

Peço desculpas pelas enormes palavras: P