Perché Oracle varchar2 ha una dimensione obbligatoria come parametro di definizione?

Question

Desidero sapere perché Oracle ha bisogno del parametro size nella definizione dello VARCHAR2.

Penso che sia per il vincolo. Sarebbe un'opzione migliore che oracle accetta questo parametro come opzionale come NUMBER dataType?

Spesso ho problemi a ridimensionare le tabelle precedenti in dimensioni più grandi, perché a volte un valore è maggiore della definizione della dimensione della colonna VARCHAR2.

È lo stesso per definire un tipo di VARCHAR2(10 o VARCHAR2(1000).

Immagino sia un vincolo non necessario. In caso contrario, sai di un caso reale quando questo vincolo ha portato a qualcosa di utile? E perché nessuna di queste dichiarazioni nel tipo NUMBER?

Answer 1

È lo stesso per definire un tipo di varchar2 (10) o varchar2 (1000).

No, non è la stessa cosa.

1. La lunghezza della colonna è metadati utili per gli sviluppatori che creano schermate.
2. Analogamente strumenti di query automatici come TOAD e SQL Developer utilizzano la lunghezza della colonna quando restituiscono risultati.
3. Il database utilizza la lunghezza di una variabile durante l'allocazione della memoria per le raccolte PL/SQL. Poiché la memoria esce dal PGA, la sostituzione della dichiarazione delle variabili può portare al fallimento dei programmi perché il server ha esaurito la memoria.
4. Ci sono problemi simili con la dichiarazione di singole variabili nei programmi PL/SQL, è solo che le raccolte tendono a moltiplicare il problema.
5. Le colonne supersized creano problemi per gli indici composti. Il seguente è su un database con 8k blocchi

....

SQL> create table t23 (col1 varchar2(4000), col2 varchar2(4000)) 
    2/

Table created. 

SQL> create index t23_i on t23(col1,col2) 
    2/
create index t23_i on t23(col1,col2) 
         * 
ERROR at line 1: 
ORA-01450: maximum key length (6398) exceeded 


SQL> 

Ma sopra ogni altra cosa, colonne dimensioni sono una forma di controllo degli errori. Se la colonna deve avere una lunghezza di dieci caratteri e un processo autonomo tenta di caricare un migliaio di caratteri, allora qualcosa non va. Il processo dovrebbe fallire, così possiamo indagare sul motivo per cui stiamo caricando i dati di Duff. L'alternativa è un database pieno di spazzatura e, se questo è ciò che si voleva, dovremmo aver dato a tutti Excel e averlo fatto.

È vero che cambiare la dimensione della colonna quando si scopre che abbiamo sottovalutato può essere noioso. Ma non succede molto spesso e possiamo mitigare un sacco di dolore usando le dichiarazioni di% TYPE e SUBTYPE nel nostro PL/SQL invece delle lunghezze variabili hard-coding.

---

"il motivo per cui tale dichiarazione tipo di numero"

numeri sono diversi. Per cominciare, la dimensione massima di un numero è molto più piccola dell'equivalente del testo (38 cifre di precisione garantita).

Ma la differenza chiave è che Oracle memorizza i valori numerici in scientific notation quindi non esiste una relazione diretta tra la dimensione aritmetica del numero e lo spazio di archiviazione che consuma.

SQL> select vsize(123456789) n1 
    2   , vsize(999999999999999999999999999999) n2 
    3   , vsize(0.000000000000000000001) n3 
    4   , vsize(1000000000000000000000000) n4 
    5 from dual 
    6/

     N1   N2   N3   N4 
---------- ---------- ---------- ---------- 
     12   16   2   2 

SQL> 

Tuttavia, rimane buona pratica per specificare scala e la precisione nella misura del possibile, soprattutto quando si tratta di numeri interi, per esempio, o il denaro.

Answer 2

Anche se non assegna un determinato numero di byte su disco come un campo char sarebbero, ci sono ancora motivi discreti di dimensionamento:

• allocazione di memoria su lettori di dati (in base alla dimensione massima di riga)
• l'indicizzazione di un grande colonna porta blocchi di dimensioni in gioco
• Etc ...

sono sicuro che ci sono più motivi che qualcun altro può pensare, ma questi sono quelli che ho visto in un passato proj ect dove qualcuno ha scelto di varchar2(4000) tutto.

Answer 3

Perché non tutte le colonne di ogni tabella di database sono CLOB? In questo modo non dovete preoccuparvi di lunghezze massime ...

Ma, sul serio:

vincoli di lunghezza Tipo di dati sono lì per lo stesso motivo di vincoli: riducono la quantità di controllo degli errori è necessario per spruzzare tutto il codice dell'applicazione, assicurando che tutti i dati archiviati correttamente nella tabella rispettino i vincoli che hai definito.

Answer 4

Dal punto di vista dell'estrazione di informazioni, è molto utile sapere quanto è grande il campo. Ad esempio, se devi stampare l'indirizzo su una busta o visualizzarlo su uno schermo, vuoi sapere quanto deve essere grande il campo.

Oppure acquistare buste MOLTO grandi.

Answer 5

Penso che sia importante ricordare il contesto storico in cui sono stati sviluppati i database relazionali. All'epoca in cui si stavano sviluppando (tra gli anni '70 e i primi anni '80) i computer comunemente disponibili erano molto più piccoli (in termini di memoria e spazio su disco) e meno potenti (in termini di CPU) di quanto ne abbiamo ora, e la gestione di queste risorse era necessariamente preoccupazione irresistibile. COBOL era il linguaggio comune del business computing (ed è ancora ampiamente utilizzato), e linguaggi orientati agli oggetti come Smalltalk e C++ erano sconosciuti, per tutti gli scopi pratici. A quel tempo ci si aspettava che i programmi dichiarassero esattamente la quantità di spazio di cui avrebbero bisogno per ogni elemento di dati, ad es. 10 byte per una stringa, 2 byte per un intero breve, 4 byte per un float, ecc. E così questo stile di dichiarazione è stato utilizzato dai database relazionali di nuova concezione. Più precisamente, l'ipotesi è stata stabilita in base alla quale ogni elemento di dati dichiarava (implicitamente o esplicitamente) la quantità di memoria richiesta e questo era codificato nei motori relazionali a un livello molto fondamentale.

Ora, nel tempo questo requisito si è leggermente allentato, almeno per quanto riguarda la memorizzazione dei dati sul disco. Credo che in Oracle il tipo di dati NUMBER ridurrà in modo flessibile lo spazio in modo che venga effettivamente utilizzata solo la quantità minima di spazio necessaria per archiviare il suo valore e che le colonne VARCHAR2 utilizzino lo spazio su disco sufficiente per archiviare i dati effettivi senza memorizzare spazi finali finali, sebbene sia ancora necessario dichiarare la quantità massima di spazio di archiviazione necessaria per un VARCHAR2.

Si potrebbe dare un'occhiata al SYS.Pacchetto STANDARD per avere un'idea di come dichiarare i sottotipi di VARCHAR2. Ad esempio, se si voleva il proprio tipo 'string', che si può usare senza virare su una specifica lunghezza si potrebbe provare:

SUBTYPE MY_STRING IS VARCHAR2(4000); 

Tuttavia, diffidare di questo se avete intenzione di indice di colonna in questione (come sottolineato in precedenza da @APC).

Sono d'accordo sul fatto che preferirei semplicemente dichiarare una STRING (che è, BTW, definita in SYS.STANDARD come sottotipo di VARCHAR2) senza dover dichiarare una lunghezza, ma questo non è solo il modo in cui Oracle funziona, e dato che non sto per iniziare a scrivere il mio database relazionale (ho i miei mulini a vento su cui inclinarti, grazie :-) seguirò semplicemente lo status quo.

Spero che questo aiuti.

Answer 6

C'è un possibile impatto sulle prestazioni: in MySQL, temporary tables e MEMORY tables memorizza una colonna VARCHAR come colonna a lunghezza fissa, estesa alla sua lunghezza massima.

Se si progettano colonne VARCHAR molto più grandi delle dimensioni massime necessarie, si consumerà più memoria del necessario. Questo riguarda cache efficiency, sorting speed, etc.

Così si dà la lunghezza massima che si trova sotto la stringa. come se tu avessi la lunghezza massima del personaggio 10, quindi non dare la sua lunghezza di 100 o più.