Perché i nomi di tabelle/colonne/indici Oracle sono limitati a 30 caratteri?

Question

Posso capire che molti anni fa ci sarebbe stato questo tipo di limitazione, ma oggi sicuramente questo limite potrebbe facilmente essere aumentato. Abbiamo convenzioni di denominazione per gli oggetti, ma c'è sempre un caso che si verifica dove raggiungiamo questo limite, specialmente nel nominare le chiavi esterne.

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

---

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

Ogni volta che vedo questo tipo di obiezione in-house, 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 tale scelta. Fornire loro un flag di compatibilità, aumentare le dimensioni a 4000, quindi salvarmi il tempo perso quando sto creando oggetti di dover contare costantemente su 30 per verificare che il nome sia 'OK'.

Answer 1

Credo sia lo standard ANSI.

EDIT:

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

Una versione successiva dello standard sembra opzionalmente consentire per 128 nomi dei personaggi, ma Oracle non supporta ancora questa (o ha un supporto parziale per esso, in quanto consente di 30 caratteri. Hmmm.)

Ricerca per "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 ref)

Answer 2

Oltre al punto di cagcowboy che deriva dallo standard SQL (storicamente, ho il sospetto che portano la decisione di Oracle di lo standard SQL dal momento che Oracle predata la standardizzazione di SQL), vorrei scommettere th gran parte della riluttanza a consentire identificatori più lunghi deriva dal fatto che ci sono milioni di DBA con milioni di script personalizzati che presuppongono tutti che gli identificatori siano lunghi 30 caratteri. Permettendo ad ogni riga di codice che va qualcosa come

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

di rompere improvvisamente perché la DBA 15 anni fa utilizzato VARCHAR2 (30), piuttosto che DBA_TABLES.TABLE_NAME%TYPE nello script causerebbe massiccia rivolta. Scommetto che Oracle da solo ha migliaia di posti in cui questo genere di cose è stato fatto nel corso degli anni in vari pacchetti e componenti. L'aggiornamento di tutto il codice esistente per supportare identificatori più lunghi sarebbe un tremendo progetto che quasi certamente genererebbe modo più costi in tempo per lo sviluppatore, tempo di QA e bug introdotti di recente che generare benefici.

Answer 3

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. Sospetto che l'aumento delle dimensioni consentite dei nomi dei vincoli influenzi significativamente la capacità di segnalare le violazioni (in particolare laddove una violazione dei vincoli è stata introdotta da alcuni livelli di codice PL/SQL).

Answer 4

ok, la limitazione esiste ....

ma non si ha realmente bisogno di più di 30 caratteri per citarne un tavolo/index/colonna ??

durante la scrittura di query, con questa limitazione ho ancora trovare alcuni nomi di colonna/tabella fastidioso. Se il limite fosse superiore mi potrebbe incorrere in tabelle che hanno richiesto 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

Answer 5

Credo che la lunghezza identificativo di 30 caratteri viene da COBOL che è stato standardizzato in la fine degli anni '50. Poiché i programmi COBOL erano l'utente principale di SQL (e SEQUEL prima di questo (e QUEL prima di quello)), questo deve essere sembrato un numero ragionevole per la lunghezza dell'identificatore.

Answer 6

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 vincoli di chiave

FK_<table1>_<table2> 

limiti nomi di tabella o inferiore 13 caratteri; la maggior parte dei database avrà bisogno di più prefissi e suffissi, limitando ulteriormente la lunghezza dei nomi delle tabelle.

Answer 7

Tutti questi vincoli '' vengono lasciati risposte alle limitazioni imposte dalle architetture di processore che provengono dagli anni '70. Poiché i processori del tempo si sono evoluti al punto che queste limitazioni non sono più necessarie; sono appena rimasti. Tuttavia, cambiarli è un grosso affare per gli scrittori del RDBMS. Dal momento che questi limiti di lunghezza influiscono su tutto il processo a valle cambiandolo a piacere per dire che un nome più lungo può e probabilmente romperà molte altre cose, come la segnalazione in esecuzione, il dizionario dei dati, ecc., Ecc. Ecc. Avrei bisogno di una grande riscrittura di Oracle RDBMS.

Answer 8

Tutte le osservazioni di cui sopra sono di destra, ma è necessario tenere a mente il costo delle prestazioni dei nomi più lunghi. Nei primi anni '90, quando Informix allestì un enorme cartellone "Informix Faster Than Oracle!" sulla route 101 accanto alla sede di Oracle, Informix ha consentito che i nomi delle tabelle fossero solo più brevi di 18 caratteri! La ragione è ovvia: i nomi delle tabelle nella loro forma letterale (vale a dire come nomi effettivi anziché "t138577321" o qualcosa del genere) sono memorizzati nel dizionario dei dati. Nomi più lunghi equivalgono a un dizionario dati più ampio e poiché il dizionario dati viene letto ogni volta che una query richiede un'analisi complessa, un dizionario dati più grande equivale a prestazioni scadenti ...

Answer 9

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

Al contrario, lo spazio dei nomi ODBC proviene da un luogo molto diverso, in cui i set di dati vengono estratti rapidamente analizzando una tabella in un foglio Excel e creando automaticamente tabelle di database con i nomi di colonna 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 casi misti. È un'astrazione sensata perché modella il modo in cui pensano gli analisti dei dati di oggi.

Non importa SQL92, è la conformità ODBC che è davvero importante per il database universale di oggi, e altri fornitori hanno affrontato questo meglio di Oracle.Anche Teradata, ad esempio, che non è visto da molti come un giocatore pervasivo, si occupa di DUE spazi dei nomi, con e senza le virgolette, il primo con un limite di 30 caratteri, il secondo un'implementazione ODBC completa in cui sono previsti bizzarri identificatori lunghi .

Anche nella tradizionale arena di database di grandi dimensioni, 30 caratteri è spesso un problema in cui i nomi devono rimanere significativi, coerenti e memorabili. Una volta che inizi a progettare strutture specializzate con l'ereditarietà di ruolo, inizierai ad abbreviare le abbreviazioni e l'uniformità presto muore, perché ad esempio lo stesso identificatore radice reso come nome di una tabella o di colonna avrà in un caso bisogno di ulteriore abbreviazione e nell'altra non . Se gli utenti reali in numeri significativi sono invitati a tali livelli, le conseguenze sono un'usabilità molto scarsa e, fortunatamente per qualsiasi database obsoleto, l'unità principale ora consiste nel separare l'utente dal database tramite i livelli degli oggetti e gli strumenti di BI.

Questo lascia il livello del database al DBA e ai team di data architect, che forse non sono così preoccupati. Elaborare schemi di abbreviazioni è ancora un lavoro per la vita, a quanto pare.

Che Oracle non abbia affrontato questa vecchia limitazione forse riflette principalmente sul fatto che non sta (ancora) perdendo molto business per la sua concorrenza quando non può portare direttamente progetti di database costruiti usando identificatori più lunghi.

Answer 10

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

Ad un certo punto ogni DBA e sviluppatori avranno 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: questo è un collegamento alla documentazione ufficiale di Oracle che spiega il cambiamento. (https://docs.oracle.com/cloud/latest/exadataexpress-cloud/CSDBF/longer-identifier-names.htm#CSDBF-GUID-F4CA155F-5A37-4705-8443-0A8C9E3F875C)

Partendo da 12c Oracle Database Release 2 (12.2), la lunghezza massima dei nomi di identificatore per la maggior parte tipi di oggetti del database è stata aumentata a 128 byte.