MySQL: Perché utilizzare VARCHAR (20) anziché VARCHAR (255)?

Question

Eventuali duplicati:
Are there disadvantages to using a generic varchar(255) for all text-based fields?

In MySQL è possibile scegliere una lunghezza per il tipo di campo VARCHAR. I valori possibili sono 1-255.

Ma quali sono i vantaggi se si utilizza VARCHAR (255) che è il massimo anziché VARCHAR (20)? Per quanto ne so, la dimensione delle voci dipende solo dalla lunghezza reale della stringa inserita.

dimensioni (byte) = lunghezza + 1

Quindi, se avete la parola "Esempio" in un campo VARCHAR (255), avrebbe dovuto 8 byte. Se lo si possiede in un campo VARCHAR (20), avrebbe anche 8 byte. Qual è la differenza?

Spero che tu possa aiutarmi. Grazie in anticipo!

Answer 1

Partenza: Reference for Varchar

In breve, non c'è molta differenza a meno che non si va oltre la dimensione di 255 nel vostro VARCHAR che richiederà un altro byte per il prefisso di lunghezza.

La lunghezza indica più di un vincolo sui dati memorizzati nella colonna di qualsiasi altra cosa. Questo intrinsecamente limita anche la dimensione di archiviazione MASSIMA per la colonna. IMHO, la lunghezza dovrebbe avere senso rispetto ai dati. Se si memorizza un # di sicurezza sociale, non ha senso impostare la lunghezza a 128 anche se non costa nulla in archivio se tutto ciò che si archivia effettivamente è un SSN.

Answer 2

Bene, se si desidera consentire una voce più grande, o limitare la dimensione della voce, forse.

Ad esempio, si potrebbe avere first_name come VARCHAR 20, ma forse street_address come VARCHAR 50 poiché 20 potrebbe non essere spazio sufficiente. Allo stesso tempo, potresti voler controllare quanto può essere grande quel valore.

In altre parole, è stato impostato un limite di quanto grande può essere un valore particolare, in teoria per evitare che la tabella (e potenzialmente le voci di indice/indice) diventino troppo grandi.

si potrebbe utilizzare CHAR che è una larghezza fissa pure, ma a differenza di VARCHAR che può essere più piccolo, CHAR pastiglie dei valori (anche se questo comporta l'accesso SQL più veloce.

Answer 3

Da una performance prospettiva di database saggio che faccio Non credo che ci sarà una differenza

Tuttavia, penso che gran parte della decisione sulla lunghezza da utilizzare si riduce a ciò che si sta cercando di realizzare e documentando il sistema per accettare solo i dati di cui ha bisogno.

Answer 4

Ci sono molti validi motivi per scegliere un valore inferiore al massimo che ar e non correlato alle prestazioni. L'impostazione di una dimensione aiuta a indicare il tipo di dati che si stanno archiviando e può anche fungere da ultima forma di convalida.

Ad esempio, se si memorizza un codice postale nel Regno Unito, sono necessari solo 8 caratteri. L'impostazione di questo limite aiuta a chiarire il tipo di dati che stai memorizzando. Se scegli 255 caratteri, confonderesti solo le cose.

Answer 5

C'è una differenza semantica (e credo che sia l'unica differenza): se cerchi di riempire 30 caratteri non spaziali in varchar (20), genererà un errore, mentre avrà successo per varchar (255) . Quindi è principalmente un ulteriore vincolo.

Answer 6

Non so su mySQL ma in SQL Server consente di definire campi in modo che il numero totale di byte utilizzati sia maggiore del numero totale di byte che possono essere effettivamente memorizzati in un record. Questa è una brutta cosa Prima o poi otterrai una riga in cui viene raggiunto il limite e non puoi inserire i dati.

È molto meglio progettare la struttura del database per considerare i limiti delle dimensioni delle righe.

Inoltre sì, non si desidera che le persone inseriscano 200 caratteri in un campo in cui il valore massimo dovrebbe essere 10. Se lo fanno, sono quasi sempre dati errati.

Si dice, beh, posso limitarlo a livello di applicazione. Ma i dati non entrano nel database solo da un'applicazione. A volte vengono utilizzate da più applicazioni, a volte i dati vengono importati e talvolta riparati manualmente dalla finestra della query (aggiornare tutti i record per aggiungere il 10% al prezzo, ad esempio). Se nessuna di queste altre fonti di dati non è a conoscenza delle regole inserite nell'applicazione, nel database saranno presenti dati non validi e inutili. L'integrità dei dati deve essere applicata a livello di database (che non ti impedisce di controllare anche prima di provare a inserire dati) o di non avere integrità. Inoltre è stata la mia esperienza che le persone che sono troppo pigre per progettare il proprio database sono spesso troppo pigre per mettere effettivamente i limiti nell'applicazione e non c'è alcun controllo sull'integrità dei dati.

Hanno una parola per i database senza integrità dei dati - inutile.