Perché i nomi di tabella / colonna / indice Oracle sono limitati a 30 caratteri?

Posso capire che molti anni fa ci sarebbe questo tipo di limitazione, ma oggi sicuramente questo limite potrebbe essere facilmente aumentato. Abbiamo convenzioni di denominazione per gli oggetti, ma c'è sempre un caso che emerge quando raggiungiamo questo limite, specialmente nella denominazione di chiavi esterne.

Qualcuno sa davvero perché questa non è una dimensione più grande - o è più grande in 11g?

Apparentemente la risposta è che interromperà gli script attualmente non codificati in modo difensivo. Dico che è una cosa molto preoccupante, Oracle sta cercando di essere il database, sicuramente questo è il tipo di cosa che devi costantemente migliorare, altrimenti il ​​tuo prodotto morirà con la morte di mille tagli.

Ogni volta che vedo questo tipo di obiezione internamente, penso che sia ora di mordere il proiettile e risolverlo. Se le persone eseguono script che non controllano o mantengono quando aggiornano le versioni di Oracle, lascia che subiscano le conseguenze di quella scelta. Fornisci loro un flag di compatibilità, fino alla dimensione di 4000, quindi risparmiami il tempo sprecato quando creo oggetti di cui contare costantemente fino a 30 per verificare che il nome sia "OK".

Credo che sia lo standard ANSI.

MODIFICARE:

In realtà, penso che sia lo standard SQL-92.

Una versione successiva dello standard sembra consentire facoltativamente nomi di 128 caratteri, ma Oracle non lo supporta ancora (o ha un supporto parziale per esso, nella misura in cui consente 30 caratteri. Hmmm.)

Cerca "F391, identificatori lunghi" in questa pagina ... http://stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/ap_standard_sql001.htm

(Alla ricerca di un riferimento)

Oltre al punto di cagcowboy che deriva dallo standard SQL (storicamente, sospetto che la decisione di Oracle abbia portato allo standard SQL poiché Oracle ha preceduto la standardizzazione di SQL), scommetterei che buona parte della riluttanza a consentire identificatori più lunghi proviene da la consapevolezza che ci sono milioni di DBA con milioni di script personalizzati che tutti presumono che gli identificatori siano lunghi 30 caratteri. Consentire ogni riga di codice simile a qualcosa

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

rompersi improvvisamente perché il DBA 15 anni fa usava VARCHAR2 (30) piuttosto che DBA_TABLES.TABLE_NAME%TYPEnella sceneggiatura avrebbe provocato un'enorme rivolta. Scommetto che solo Oracle ha migliaia di posti in cui questo genere di cose è stato fatto nel corso degli anni in vari pacchetti e componenti. Retrofitting tutto ciò che il codice per supportare identificatori più esistente sarebbe un progetto enorme che avrebbe quasi certamente generare modo più costi in tempo per gli sviluppatori, il tempo di QA, e gli insetti di nuova introduzione di quello che sarebbe generare benefici.

Stavo cercando questo e ho trovato questa domanda tramite Google, ma ho anche scoperto che a partire da Oracle 12c Release 2 (12.2), questo non è più rigorosamente il caso. ( https://oracle-base.com/articles/12c/long-identifiers-12cr2 )

Ad un certo punto ogni DBA o sviluppatore avrà raggiunto un punto in cui il limite di 30 caratteri per i nomi degli oggetti ha causato un problema. Questo limite può essere estremamente doloroso quando si eseguono progetti di migrazione da SQL Server o MySQL a Oracle. In Oracle Database 12cR2, la lunghezza massima della maggior parte degli identificatori è ora di 128 caratteri.

Questa è una nuova funzionalità in 12.2, secondo ( http://blog.dbi-services.com/oracle-12cr2-long-identifiers/ ). Secondo quel post, 12.1 era ancora limitato a 30 caratteri.

Modifica: ecco un link alla documentazione ufficiale di Oracle che spiega la modifica. ( https://docs.oracle.com/cloud/latest/exadataexpress-cloud/CSDBF/longer-identifier-names.htm#CSDBF-GUID-F4CA155F-5A37-4705-8443-0A8C9E3F875C )

A partire da Oracle Database 12c versione 2 (12.2), la lunghezza massima dei nomi identificativi per la maggior parte dei tipi di oggetti di database è stata aumentata a 128 byte.

Data la necessità pratica dei limiti di lunghezza dell'identificatore, un buon design limita la lunghezza dei nomi effettivi per evitare di colpire il soffitto quando i nomi sono combinati tra loro e con prefissi e suffissi.

Ad esempio, una convenzione di denominazione dei vincoli di chiave esterna

FK_<table1>_<table2> 

limita i nomi delle tabelle a 13 caratteri o meno; la maggior parte dei database avrà bisogno di più prefissi e suffissi, limitando ulteriormente la lunghezza dei nomi delle tabelle.

Le violazioni dei vincoli vengono segnalate in SQLERRM che è limitato a 255 caratteri e che la maggior parte dei client utilizza per rendere visibili gli errori. Ho il sospetto che aumentare in modo significativo la dimensione consentita dei nomi dei vincoli avrebbe un impatto sulla capacità di riferire sulle violazioni (specialmente laddove una violazione del vincolo sia stata gorgogliata attraverso alcuni strati di codice PL / SQL).

Credo che la lunghezza dell'identificatore di 30 caratteri provenga da COBOL, che è stato standardizzato alla fine degli anni '50. Poiché i programmi COBOL erano l'utente principale di SQL (e SEQUEL prima (e QUEL prima)), questo doveva sembrare un numero ragionevole per la lunghezza dell'identificatore.

Tutti questi "vincoli" sono lasciati alle risposte alle limitazioni imposte dalle architetture dei processori che provengono dagli anni '70. Da quel momento i processori a tempo si sono evoluti al punto che tali limiti non sono più necessari; sono appena rimasti. Tuttavia, cambiarli è un GRANDE affare per gli scrittori del RDBMS. Poiché questi limiti di lunghezza influiscono su tutto ciò che si trova a valle cambiandolo volenti o nolli per adattarsi, si può dire che un nome di procedura più lungo può e probabilmente romperà molte altre cose come la segnalazione di esecuzioni, il dizionario dei dati, ecc. E così via. Richiederei un'importante riscrittura di Oracle RDBMS.

La risposta diretta alla domanda è che lo stile Oracle è ereditato da idee precedenti in cui 30 sembravano molto, e molto di più avrebbe aumentato il rischio di sbloccare la cache del dizionario dalla memoria reale nei database tipici.

Al contrario, lo spazio dei nomi ODBC proviene da una posizione molto diversa, in cui i set di dati vengono estratti rapidamente analizzando una tabella in un foglio Excel e costruendo automaticamente tabelle di database con nomi di colonne presi dalle intestazioni delle tabelle dei fogli. Pensare in questo modo ti porta a consentire identificatori che contengono persino ritorni a capo incorporati e, naturalmente, caratteri speciali e maiuscole / minuscole. È un'astrazione ragionevole perché modella il modo in cui pensano gli analisti di dati di oggi.

Non importa SQL92, è la conformità ODBC che conta davvero per il database universale di oggi e altri fornitori lo hanno affrontato meglio di Oracle. Anche Teradata, ad esempio, che non viene visto da molti come un giocatore pervasivo, si rivolge a DUE spazi dei nomi, con e senza virgolette, il primo con un limite di 30 caratteri, il secondo un'implementazione ODBC completa in cui vengono presi in considerazione strani identificatori lunghi .

Anche nella tradizionale arena di database di grandi dimensioni, 30 caratteri sono spesso un problema in cui i nomi devono rimanere significativi, coerenti e memorabili. Una volta che inizi a progettare strutture specializzate con eredità con nome di ruolo, inizierai ad abbreviare le abbreviazioni e presto la coerenza muore, perché ad esempio lo stesso identificatore di radice reso come un nome di tabella o un nome di colonna avrà bisogno in un caso di ulteriori abbreviazioni e nell'altro no . Se gli utenti reali in numero significativo vengono invitati a tali livelli, le conseguenze sono un'usabilità molto scarsa e fortunatamente per qualsiasi database obsoleto, l'unità principale ora è quella di separare l'utente dal database tramite livelli oggetto e strumenti di BI.

Questo lascia il livello del database al DBA e ai team di architetto dei dati, che forse non sono infastiditi. Sembra che elaborare schemi di abbreviazioni sia ancora un lavoro per tutta la vita.

Il fatto che Oracle non abbia affrontato questa vecchia limitazione forse riflette principalmente sul fatto che non sta (ancora) perdendo molto business rispetto alla concorrenza quando non è in grado di trasferire direttamente i progetti di database creati utilizzando identificatori più lunghi.

Tutti i commenti sopra sono giusti, MA è necessario tenere presente il costo delle prestazioni di nomi più lunghi. All'inizio degli anni '90, quando Informix istituì un enorme cartellone pubblicitario "Informix Faster Than Oracle!" sulla route 101 vicino al quartier generale di Oracle, Informix consentiva nomi di tabelle più brevi di 18 caratteri! Il motivo è ovvio: i nomi delle tabelle nella loro forma letterale (ovvero come nomi effettivi anziché "t138577321" o qualcosa del genere) sono memorizzati nel dizionario dei dati. I nomi più lunghi equivalgono a Dizionario dei dati più grande e, poiché il Dizionario dei dati viene letto ogni volta che una query richiede un'analisi approfondita, un dizionario dei dati più grande equivale a prestazioni scarse ...

ok, la limitazione esiste ....

ma hai davvero bisogno di più di 30 caratteri per nominare una tabella / indice / colonna ??

quando scrivo query, con questa limitazione trovo ANCORA fastidiosi alcuni nomi di colonne / tabelle. Se il limite fosse maggiore, potrei imbattermi in tabelle che richiedono una query come:

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.

Mi scuso per le enormi parole: P