C'è una buona ragione per cui vedo VARCHAR (255) usato così spesso (al contrario di un'altra lunghezza)?

158

In più corsi, libri e lavori, ho visto i campi di testo definiti come VARCHAR (255) come il tipo di default per il testo "abbreviato". C'è qualche buona ragione per cui una lunghezza di 255 viene scelta così spesso, oltre ad essere un bel numero rotondo ? È una sospensione da qualche tempo in passato quando c'era una buona ragione (se si applica oggi o no)?

Mi rendo conto, ovviamente, che un limite più stretto sarebbe più ideale, se in qualche modo conosci la lunghezza massima della corda. Ma se stai usando VARCHAR (255) che probabilmente indica che non conosci la lunghezza massima, solo che è una stringa "abbreviata".

Nota: ho trovato questa domanda ( varchar (255) v tinyblob v tinytext ), che dice che VARCHAR ( n ) richiede n +1 byte di memoria per n <= 255, n +2 byte di memoria per n > 255. È questa l'unica ragione? Sembra un po 'arbitrario, dato che risparmieresti solo due byte rispetto a VARCHAR (256) e potresti altrettanto facilmente salvare altri due byte dichiarandolo VARCHAR (253).

— Kip
fonte

109

Storicamente, 255 caratteri è stata spesso la lunghezza massima di a VARCHARin alcuni DBMS e talvolta si rivela ancora il massimo effettivo se si desidera utilizzare UTF-8 e la colonna è indicizzata (a causa delle limitazioni della lunghezza dell'indice).

— caos
fonte

4

@CharlesBretana: se leggi il resto della frase che hai citato, troverai la spiegazione esatta che stai richiedendo.

— caos,

2

@CharlesBretana: Per "falso UTF-8" intendo la codifica "utf8" di MySQL, che come ho detto riserva (ed è limitato a) 3 byte per carattere. Questa non è una versione molto buona di UTF-8; se vuoi un UTF-8 decente in MySQL, devi usare la sua codifica "utf8mb4". Ma è molto più probabile che le persone non lo sappiano e vadano con "utf8", e molto più probabilmente desiderino UTF-8 rispetto a qualsiasi altra codifica, quindi presto finiscono con una lunghezza indicizzabile massima di 255 caratteri in un VARCHAR. Nonostante il tuo stupore.

— caos,

3

@CharlesBretana: l'ho spiegato tre volte e non è cambiata una sola cosa. Il limite di lunghezza dell'indice di MySQL è ancora 767 byte, il numero di byte necessari per codificare un carattere UTF-8 a 3 byte è ancora 3 e floor (767/3) è ancora 255. La tua determinazione a trovare qualcosa da confondere sulla convinzione dei mendicanti .

— caos,

1

@CharlesBretana (mi spiace di essere in ritardo a tutta questa festa) Non sono uno specialista di DB, ma penso che ciò che il caos sta dicendo sia: sì, una colonna "Fake UTF-8" può contenere più di 255 caratteri, ma l'indice lo farà funziona solo sui primi 255 caratteri del varchar, rendendolo effettivamente il massimo di una colonna se lo desideri completamente indicizzato. Ora è solo quello che ho capito delle sue spiegazioni, potrei sbagliarmi, non sono affatto un esperto di indici SQL.

— Francis Lord,

2

@CharlesBretana Se osservi correttamente la risposta di Chaos, noterai che è divisa in 2 parti: 1. Il motivo storico dietro Varchar (255) è così comune (era il massimo su alcuni DBMS più vecchi), 2. Ancora oggi, per alcuni è ancora una limitazione a causa delle limitazioni dell'indice discusse in precedenza, le Parti 1 e 2 non sono collegate. La parte 1 è la risposta effettiva alla domanda, la parte 2 è una nota a margine che è ancora rilevante per la domanda perché spiega perché ancora oggi potrebbe essere ancora una limitazione. (CONTINUA ->)

— Francis Lord,

161

255 viene utilizzato perché è il maggior numero di caratteri che può essere contato con un numero di 8 bit. Massimizza l'uso del conteggio a 8 bit, senza richiedere frivolosamente un altro intero byte per contare i caratteri sopra 255.

Se utilizzato in questo modo, VarChar utilizza solo il numero di byte + 1 per memorizzare il testo, quindi è possibile impostarlo su 255, a meno che non si desideri un limite rigido (come 50) sul numero di caratteri nel campo.

— Robert Harvey
fonte

90

Mi piace quella frase: "richiedere frivolosamente un altro intero byte". =)

— MusiGenesis,

7

Questo vale per i DB in cui varchars sono UTF-8?

— antak,

1

@antak: in MySQL, usando InnoDB, qualsiasi colonna chiave non può superare 767 byte. Se una colonna VARCHAR è UTF8 (il che significa che ogni carattere può richiedere fino a 3 byte), la lunghezza massima consentita della colonna è floor (767/3) = 255. Suppongo che "767" sia stato scelto proprio per questo motivo.

— BlueRaja - Danny Pflughoeft

1

Se il set di caratteri èutf8 , varchar(85)è il limite oltre il quale l'attraversamento punta il byte di lunghezza da uno a due byte. Se lo è utf8mb4, lo è varchar(63). Questi sono significativi perché sono il massimo a cui la lunghezza di un VARCHAR può essere estesa mediante l'uso di ALTER TABLE online . Di conseguenza, ho derivato quei numeri creando una tabella con una varchar(2) charset utf8colonna e vedendo fino a che punto sono stato in grado di estenderlo dato ALGORITHM=INPLACE.

— antak

Ha ancora più senso se si considera che molti "database" Back In The Day sono stati memorizzati su nastro magnetico. Era molto comune leggere i dati in "blocchi" che erano dimensionati in multipli di due. In questo modo, i dati sono stati archiviati nel modo più efficiente (e quando si eseguiva su un vecchio mainframe, piccole efficienze del genere erano ottimizzazioni "fai-da-te-o-rompe").

— TMN

23

Probabilmente perché sia SQL Server che Sybase (per citarne due con cui ho familiarità) avevano un massimo di 255 caratteri nel numero di caratteri in una VARCHARcolonna. Per SQL Server, questo è cambiato nella versione 7 nel 1996/1997 o giù di lì ... ma a volte le vecchie abitudini sono dure a morire.

— Charles Bretana
fonte

8

+1 per citare DB e versioni specifici. E "Le vecchie abitudini sono dure a morire" è probabilmente la risposta più vera di tutte.

— Andrew M,

17

Risponderò alla domanda letterale: no , non c'è una buona ragione per cui vedi VARCHAR (255) usato così spesso (ci sono davvero ragioni , come discusso nelle altre risposte, ma non buone). Non troverai molti esempi di progetti falliti catastroficamente perché l'architetto ha scelto VARCHAR (300) anziché VARCHAR (255). Questo sarebbe un problema di insignificanza quasi totale anche se si stesse parlando di CHAR anziché di VARCHAR.

— MusiGenesis
fonte

1 byte su 255 è 0,4%. A volte ti importa dell'ultimo mezzo percento circa. A volte no. Se i costi di hosting e perf ammontano a decine di dollari, probabilmente non ti interessa. Se si imbattono in milioni, probabilmente lo fanno.

— Edward Brey,

2

@EdwardBrey: se la Legge di Moore è ancora valida, la mia risposta qui è 16 volte più valida di quando l'ho scritta.

— MusiGenesis,

A meno che non abbiamo scoperto 16 volte più modi in cui i computer possono aiutarci. La velocità è ancora una caratteristica.

— Edward Brey,

14

Quando dici 2^8di ottenere 256, ma i numeri in termini di computer iniziano dal numero 0. Quindi, quindi hai il 255, puoi sondarlo in una maschera di Internet per l'IP o nell'IP stesso.

255 è il valore massimo di un numero intero a 8 bit: 11111111 = 255

Questo aiuta?

— exec.-
fonte

1

Con numeri interi, conti a partire da 0 e finisci a 255. Ma con i posti in una stringa, conti a partire dal 1 ° posto, quindi non ha senso finire al 256 ° posto, perché hai iniziato da 1 invece di 0? Non sono ancora completamente d'accordo con varchar (256), a causa dei risultati string_length (), ma in realtà non ne sono sicuro.

— HoldOffHunger

1

Le stringhe di @HoldOffHunger in un database possono avere una lunghezza di zero caratteri, quindi l'intervallo consentito di lunghezze quando la lunghezza è memorizzata in otto bit è compreso tra 0 e 255. Se si desidera dire che tutte le stringhe devono avere almeno un carattere, è necessario potrebbe supportare stringhe di 256 caratteri con una lunghezza di otto bit.

— phoog

7

Nota: ho trovato questa domanda ( varchar (255) v tinyblob v tinytext ), che dice che VARCHAR ( n ) richiede n +1 byte di memoria per n <= 255, n +2 byte di memoria per n > 255. È questa l'unica ragione? Sembra un po 'arbitrario, dato che risparmieresti solo due byte rispetto a VARCHAR (256) e potresti altrettanto facilmente salvare altri due byte dichiarandolo VARCHAR (253).

No. Non si risparmiano due byte dichiarando 253. L'implementazione di varchar è molto probabilmente un contatore di lunghezza e un array non terminato a lunghezza variabile. Ciò significa che se memorizzi "ciao" in un varchar (255) occuperai 6 byte: un byte per la lunghezza (il numero 5) e 5 byte per le cinque lettere.

— Stefano Borini
fonte

3

Questa affermazione non è vera per tutti i database. molti database utilizzano campi varchar delle dimensioni indicate nelle tabelle in modo che non debbano spostare le righe quando quel campo viene modificato per una riga.

— SingleNegationElimination

si hai ragione. dipende dall'implementazione. Devi controllare il manuale del venditore per vedere qual è il caso

— Stefano Borini,

2

Può essere lecito, ma implementare in VARCHARquesto modo sconfigge l'intero punto di utilizzo VARCHARanziché CHAR.

— dan04,

4

Un numero di 1 byte senza segno può contenere l'intervallo [0-255] incluso. Quindi, quando vedi 255, è principalmente perché i programmatori pensano in base 10(prendi la battuta?) :)

In realtà, per un po ', 255 è stata la dimensione più grande che potresti dare a VARCHAR in MySQL e ci sono vantaggi nell'usare VARCHAR su TEXT con indicizzazione e altri problemi.

— gahooa
fonte

4

In molte applicazioni, come MsOffice (fino alla versione 2000 o 2002), il numero massimo di caratteri per cella era 255. Spostare i dati da programmi in grado di gestire più di 255 caratteri per campo verso / da quelle applicazioni era un incubo. Attualmente, il limite è sempre meno difficile.

— Joaquin Montes
fonte

2

0000 0000 -> questo è un numero binario a 8 bit. Una cifra rappresenta un po '.

Conti così:

0000 0000 → (0)

0000 0001 → (1)

0000 0010 → (2)

0000 0011 → (3)

Ogni bit può avere uno di due valori: on o off. Il numero più alto totale può essere rappresentato dalla moltiplicazione:

2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 - 1 = 255

O

2^8 - 1.

Ne sottraggiamo uno perché il primo numero è 0.

255 può contenere un bel po '(nessun gioco di parole previsto) di valori.

Man mano che utilizziamo più bit, il valore massimo aumenta esponenzialmente. Pertanto, per molti scopi, l'aggiunta di più bit è eccessiva.

— ScottyBlades
fonte

1

Un altro motivo potrebbe essere che nelle vecchie librerie di accesso ai dati su Windows come RDO e ADO (versione COM non ADO.NET) è stato necessario chiamare un metodo speciale, GetChunk, per ottenere dati da una colonna con più di 255 caratteri. Se hai limitato una colonna varchar a 255, questo codice aggiuntivo non era necessario.

— Booji Boy
fonte