MySQL: Perché usare VARCHAR (20) al posto di VARCHAR (255)? [duplicare]

Question

  

Eventuali duplicati:
   Ci sono svantaggi ad usare un varchar generico (255) per tutti i campi basati su testo?

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

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

dimensione (bytes) = lunghezza + 1

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

Spero che mi può aiutare. Grazie in anticipo!

Answer 1

Check out: di riferimento per 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 archiviati nella colonna di ogni altra cosa. Ciò limita intrinsecamente il formato massimo di conservazione per la colonna pure. IMHO, la lunghezza dovrebbe dare un senso per quanto riguarda i dati. Se la memorizzazione di un Social Security # non ha senso per impostare la lunghezza di 128, anche se non ti costa nulla in deposito se tutto quello che in realtà è un negozio di SSN.

Answer 2

Ci sono molti validi motivi per scegliere un valore inferiore a quello massimo, che non sono legati alla performance. L'impostazione di una dimensione aiuta indicare il tipo di dati che archiviano e può anche agire anche come una forma in extremis di convalida.

Per esempio, se si archiviano un codice postale del Regno Unito allora dovete solo 8 caratteri. L'impostazione di questo limite contribuisce a rendere chiaro il tipo di dati si memorizzano. Se si è scelto di 255 caratteri sarebbe solo confondere le cose.

Answer 3

Non so su MySQL, ma in SQL Server vi permetterà di definire i campi in modo tale che il numero totale di byte utilizzati è superiore al numero totale di byte che possono essere effettivamente memorizzati in un record. Questa è una brutta cosa. Prima o poi avrete una riga in cui si raggiunge il limite e non è possibile inserire i dati.

E 'di gran lunga migliore per progettare la struttura del database di prendere in considerazione limiti di dimensione fila.

Inoltre sì, non si vuole che la gente a mettere 200 caratteri in un campo dove il valore massimo dovrebbe essere 10. Se lo fanno, è quasi sempre dati errati.

Tu dici, bene posso limitare che a livello di applicazione. Ma i dati non ottiene nel database solo da un'applicazione. A volte più applicazioni lo usano, a volte tecnica è importata e, talvolta, è fissato manualmente dalla finestra di query (aggiornare tutti i record da aggiungere il 10% al prezzo, per esempio). Se una di queste altre fonti di dati non conoscono le regole che mettete nella vostra applicazione, si avrà, dati inutili cattivi nel database. L'integrità dei dati deve essere applicata a livello di database (che non ti impedisce di anche il controllo prima di tentare di inserire i dati) o non avete integrità. In più è stata la mia esperienza che le persone che sono troppo pigri per progettare il loro database sono spesso anche troppo pigro per mettere in realtà i limiti nell'applicazione e non v'è alcun controllo di integrità dei dati a tutti.

Hanno una parola per i database senza l'integrità dei dati -. Inutile

Answer 4

C'è una differenza semantica (e credo che sia l'unica differenza): se si tenta di riempire 30 caratteri non-spazio in varchar (20), che produrrà un errore, mentre riuscirà a varchar (255). Quindi è soprattutto un vincolo aggiuntivo.

Answer 5

Bene, se si desidera consentire per una voce più grande, o limitare le dimensioni di entrata, forse.

Ad esempio, si può avere first_name come VARCHAR 20, ma forse STREET_ADDRESS come VARCHAR 50 dal 20 potrebbe non essere sufficiente spazio. Allo stesso tempo, si consiglia di controllare il modo grande che valore può avere.

In altre parole, è stato impostato un soffitto di quanto grande un particolare valore può essere, in teoria, per evitare che il tavolo (e potenzialmente le voci di indice / index) di ottenere troppo grande.

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 6

Da un punto di vista delle prestazioni del database saggio non credo ci sta per essere una differenza.

Tuttavia, credo che un sacco di decisione sulla lunghezza da utilizzare si riduce a ciò che si sta cercando di realizzare e documentare il sistema di accettare solo i dati di cui ha bisogno.