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



Answers

Oltre al punto di cagcowboy che deriva dallo standard SQL (storicamente, sospetto che la decisione di Oracle abbia portato allo standard SQL dal momento che Oracle ha preceduto la standardizzazione di SQL), scommetterei che gran parte della riluttanza a consentire identificatori più lunghi proviene da la consapevolezza che ci sono milioni di DBA con milioni di script personalizzati che presuppongono tutti che gli identificatori siano lunghi 30 caratteri. Permettendo ogni linea di codice che va qualcosa come

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

interrompere improvvisamente perché il DBA 15 anni fa utilizzava VARCHAR2 (30) anziché DBA_TABLES.TABLE_NAME%TYPE nello script DBA_TABLES.TABLE_NAME%TYPE una 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 più costi in termini di tempo di sviluppo, QA e bug appena introdotti che non ne genererebbe benefici.

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 database, sicuramente questo è il genere di cose che devi costantemente migliorare, altrimenti il ​​tuo prodotto morirà di mille tagli.

Ogni volta che vedo in casa questo tipo di obiezione, 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'.




Credo che la lunghezza dell'identificatore di 30 caratteri provenga dal COBOL, standardizzato alla 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.




La risposta diretta alla domanda è che lo stile Oracle è ereditato da idee vecchie in cui 30 sembravano molto, e molto 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 un luogo molto diverso, in cui i set di dati vengono estratti rapidamente analizzando una tabella in un foglio di 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 produttori hanno affrontato questo problema 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.

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

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




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




ok, la limitazione esiste ....

ma hai davvero bisogno di più di 30 caratteri per nominare un tavolo / indice / colonna ??

quando si scrivono query, con questa limitazione, ANCORA trovo fastidiosi alcuni nomi di colonne / tabelle. Se il limite fosse più alto potrei imbattermi in tabelle che richiedevano 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




Related