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


149

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'.


3
Desde que precisa haver um limite? Crie 64 caracteres e você provavelmente encontrará alguém perguntando por que não é 128 etc. Quanto tempo dura um pedaço de barbante?
O presidente

45
É verdade, mas 30 é um pedaço muito curto de barbante. Por que não pode ser 4000 - do tamanho de um Varchar2 - a Oracle realmente se importa quanto tempo demora uma vez que analisou a consulta?
Chris Gill

22
O PostgreSQL do @TheChairman me limita a 63 caracteres, e nunca tive problemas com esse limite de comprimento. É grande o suficiente para que meus nomes se ajustem e, se eu estiver pensando em um nome mais longo, é hora de começar a pensar no impacto negativo na legibilidade. Por outro lado, frequentemente encontro limites de tamanho de nome no Oracle e sou forçado a reduzir a legibilidade do meu nome por causa do limite de 30 caracteres. Algumas pessoas podem reclamar de um limite de 64, mas muitas pessoas já têm problemas por causa do limite de 30 caracteres. Trata-se de atender 99% dos casos de uso, e o Oracle falha aqui.
Jpmc26

1
Vamos, Oracle, você se tornou um dinossauro! A Microsoft está fazendo um bom trabalho para tornar o servidor SQL mais amigável. Agora relaxe a restrição de comprimento do nome.
user3454439

1
Avançando rapidamente para o Oracle 12cR2, agora são 128 bytes em vez de 30 :-) docs.oracle.com/en/database/oracle/oracle-database/12.2/newft/…
Stefan L

Respostas:


71

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)


1
Hmm, não foi assim que li esse documento. Diz-me que F391 é um item na especificação SQL / Foundation (o que quer que seja) e que a Oracle tem suporte parcial para isso, com um limite de 30 caracteres.
22410 skaffman

21
Parcialmente conformidade. Que piada. "nossos parafusos cumprem parcialmente os padrões métricos, exceto que não são métricos".
Jens Schauder

5
Não li as especificações do F391 em detalhes, mas estou assumindo (talvez incorretamente) que "Identificadores longos" significam um aumento no tamanho do identificador de 30 para 128. Dizer que você "parcialmente" suporta isso permitindo 30 caracteres é um pouco atrevido. Você não suporta o novo padrão, ainda suporta o padrão antigo (embora 25% do caminho para o novo padrão) Isso fazia sentido? !!?
Cagcowboy 04/09/09

7
O padrão SQL-92 está aqui contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt , mas se você ler a seção "17.1 Descrição das áreas do descritor de itens SQL", diz que identificadores como nomes e esquemas devem permitir pelo menos 128 personagens.
411 Rick

46
O fato de os fãs do Oracle não verem a utilidade de mais de 30 identificadores de caracteres é perturbador. "Torne seus nomes significativos / descritivos, use sublinhados em vez de estojo de camelo e fique com menos de 30 caracteres". Isso nunca ultrapassaria 30 caracteres. Amirita? É mais como abreviar suas abreviações e quando nenhum dos nomes faz sentido, passe o dia todo lendo / atualizando a documentação.
Adam Jones

45

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.


13
+1 Este é quase certamente um dos muitos aleijados de design herdados da Oracle.
22410 skaffman

43
Certamente é hora de aumentar um par e aumentá-lo - adicione uma sinalização para que os DBAs possam refinar de volta para 30. Questões herdadas como essa sempre devem ser enfrentadas e classificadas, caso contrário, você acaba prejudicando toda a base de código e as pessoas simplesmente se movem para outra coisa
Chris Gill

6
Não apenas milhões de linhas de código escrito DBA, mas também muito código interno da Oracle, sem dúvida. Este tópico surgiu em uma sessão com Steven Feuerstein e ele disse que não achava que eles jamais mudariam isso.
Matthew Watson

10
Eles também não conseguiam justificá-lo como um novo recurso ... eles passavam muito tempo estendendo o limite e anunciavam "agora você pode usar nomes com mais de 30 caracteres!". Eles seriam motivo de chacota.
21410 skaffman

9
Se você ainda usa scripts de 15 anos, algo está extremamente errado . Além disso, consertá-los seria um custo único (possivelmente com um pouco mais para manutenção continuada), enquanto os desenvolvedores continuarão perdendo tempo criando desnecessariamente nomes horrivelmente abreviados por tempo indeterminado. @skaffman Eles já são motivo de chacota por não consertá-lo (e uma série de outras decisões de design que são patéticas na era moderna, como nenhum tipo booleano ou de incremento automático), no que me diz respeito.
Jpmc26 # 6/15

11

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.


128 bytes / 4 bytes (Unicode) = 32 caracteres. Pelo menos, meu entendimento é que 4 bytes para caracteres não Unicode não são incomuns? Eu tenho que saber se isso significa apenas que eles estão suportando Unicode agora? Assim como VARCHAR2(2)não significa 2 caracteres, mas 2 bytes.
Seth

1
Entendo o seu ponto, mas os caracteres vs bytes dependem do seu conjunto de caracteres do banco de dados. Essa configuração determina a codificação para os tipos de dados char (como varchar2), bem como a codificação para identificadores db. Isso é contrastado com o conjunto de caracteres nacional, usado para tipos de dados nchar. Então, sim, se você tiver uma codificação tal que seus identificadores usem 4 bytes por caractere (supondo que tal possa ser usado como o conjunto de caracteres DB), agora você teria 32 em vez de 7. Mas acho que, na maioria dos casos, os identificadores seriam caracteres de byte único.
precisa saber é

6

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.


5

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).


Então, amplie a mesa, então?
21410 skaffman

2
Não é uma tabela, mas como o software cliente realmente obtém erros do banco de dados.
9789 Gary Myers

@skaffman O comprimento do SQLERRM é uma especificação API / ABI. Mudar isso significaria ter que consertar todos os drivers OCI do planeta (mais saturação de buffer). Eles poderiam colocar a mudança no cliente para aumentar o buflen no OCI 13 primeiro e o servidor em algo como o Oracle 15, onde os clientes do OCI 10 não seriam mais suportados, suponho. (Talvez eles estejam considerando isso agora, mas a versão principal do oracle é lançada apenas a cada poucos anos; e ainda podemos ter problemas com a atualização de script / aplicativo quando os aplicativos são migrados para servidor / cliente diferente).
cowbert

4

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.


5
Acredito que a primeira versão do Oracle foi escrita em Fortran, que acho que possui um limite de identificador de 31. Talvez isso seja relevante.
David Aldridge

4

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.


2

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.


Não para a Oracle. ODBC é um bebê da Microsoft, não um Java. É ainda um lib separado ajudante ligado contra OCI (olhada em como instantclient é implantado - a fim de se ODBC trabalhar com instantclient você precisa tanto o driver OCI e os zips instantclient ODBC). A plataforma principal do cliente da Oracle (além do Pro * C / C / C ++ legado) é o JDBC, que está diretamente vinculado ao OCI, não ao ODBC.
cowbert

1

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


7
Não há absolutamente nenhuma razão para a correspondência exata de cadeias curtas ser um gargalo em qualquer software moderno, a menos que você esteja fazendo isso bilhões de vezes - o que não é o caso na análise de consultas. As considerações de tamanho e desempenho podem ter sido significativas quando essa parte do Oracle foi projetada, mas elas não são realmente relevantes atualmente.
Sarah G

-7

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


29
Seria bom poder nomear chaves estrangeiras com os nomes das tabelas e colunas às quais elas se juntam - portanto, quando uma exceção de chave estrangeira é lançada, você não precisa procurar as colunas que causaram a falha. Então, novamente a Oracle poderia apenas dizer-lhe que info ...
Chris Gill

10
Há muitas razões pelas quais precisamos de mais de 30 caracteres, embora geralmente 30 caracteres sejam suficientes. Em algum momento, o nome de uma tabela precisa ser detalhado o suficiente para ser significativo. Por exemplo, eu tenho essa chamada de tabela sch_PatternRunTimeException, ela tem exatamente 30 caracteres. Agora, preciso adicionar uma chamada de tabela de espelhamento sch_DevPatternRunTimeException. Esse padrão de nomeação de 3 caracteres extras não está funcionando para Oracle, o MSSQL não tem nenhum problema. Isso está me forçando a criar um novo nome. Renomear tabela é factível, mas afetará as operações de nossos clientes, o que tentamos evitar.
DSoma

6
Se em 99,9% dos casos possíveis +30 caracteres são irritantes, isso não significa que eles serão úteis nos outros 0,1%.
René Nyffenegger 30/04

14
Ahhh, o argumento da ladeira escorregadia. Um limite de apenas 4 caracteres alfanuméricos nos levaria a mais de 1 milhão de combinações de tabelas, para que ninguém realmente "precise" mais de 4. No entanto, aqui estamos. E não são realmente 30 caracteres, são menos de 30 caracteres, já que minha convenção de nomenclatura de casos pascal foi descartada com a falta de distinção entre maiúsculas e minúsculas e substituída por nomes delimitados por sublinhado. Combine isso com vários prefixos / sufixos e você tem sorte de ter até 20 caracteres. Quem não preferiria que um nome de índice robusto ecoasse com um erro de violação sobre uma mistura de abreviações e sublinhados?
b_levitt

Concordou que isso não está resolvendo o problema. Normalmente, os seres humanos não precisam de nomes de coluna mais longos, mas há muitos casos em que os nomes de objetos são gerados automaticamente.
Fool4jesus
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.