Perché le lunghezze dei campi SQL sono sempre (2^n) -1 a meno di 127?

Question

Un sacco di schemi di database sembra seguire la seguente norma:

(2^n) -1 per grandi settori:

varchar(511) 
varchar(255) 
varchar(127) 

... poi (2^n) per quelli più piccoli

varchar(64) 
varchar(32) 
varchar(16) 
varchar(8) 

capisco il motivo per cui il numero di (2^n) -1 vengono utilizzati, quello che non capisco è il motivo per cui non è necessario continuare il trend verso il basso per i piccoli campi.

E.g.

varchar(63) 
varchar(31) 
varchar(15) 
varchar(7) 

C'è una ragione per questo o è solo che i rendimenti sono diminuiti troppo lontano?

Answer 1

Ricordo i vecchi tempi, quando si utilizzava 2^n Lunghezza era meglio l'allineamento dei blocchi su disco o memoria. Il blocco allineato era più veloce. Oggi le dimensioni del "blocco" sono più grandi e la memoria e il disco sono abbastanza veloci da ignorare l'allineamento, escluso per i blocchi molto grandi che è. (Qualunque cosa "molto grande" significa oggi ...)

Al giorno d'oggi è solo tradizione farlo.

E un'altra ragione il mio è il famoso detto: Ci sono solo 10 tipi di persone: quelli che possono binari e gli altri.

E 2^n -1 sono candidati per i primi di mersenne. quindi è anche geniale ...

Answer 2

Non posso dire come ho visto la tendenza "-1" utilizzata in modo diverso per campi più piccoli/più grandi. Comunque penso che non sia altro che sviluppatore/dba OCD. Volendo sempre numeri "rotondi" quando dovrebbero prendere decisioni sul campo in base alle regole di business piuttosto che alla "prettiness"

Answer 3

In realtà, è la prima volta che sento parlare di una simile "tendenza". I miei campi varchar sono sempre fintanto che ho bisogno che siano.

Direi che non c'è alcun motivo particolare dietro di esso. Solo la preferenza dello sviluppatore.

Answer 4

Non riesco a immaginare per un momento perché stanno dimensionando i campi in questo modo su entrambi i numeri 2^N o 2^N-1. Da una prospettiva di SQL Server, sembra più un equivoco su come SQL stia memorizzando i dati a livello di pagina rispetto a un motivo specifico.

Vorrei prestare maggiore attenzione ai tipi, il potenziale off stoccaggio pagina (SLOB/LOB) e le righe/pagina + incontrare il business ha bisogno di dimensionamento, di una formula basata sull'utilizzo di 2^N ecc

Answer 5

penso sono solo i programmatori che scelgono un numero in aria quando non ha molta importanza.

Se si dovesse porre un limite al campo "note", ad esempio un programmatore non selezionerebbe probabilmente 100 o 200 caratteri come numero tondo, mentre un programmatore potrebbe pensare a 127 o 255 come numero tondo.

Answer 6

Non solo i rendimenti sono diminuiti, ma se si impostano tipi di stringhe con limiti arbitrari, è molto più probabile che si verifichi un problema che risolverlo.

Se si tratta di un vincolo di business, utilizzare il tipo di TESTO (o simile) e un vincolo CHECK sulla lunghezza e selezionare il numero in base al vincolo di business che si sta tentando di applicare.

Il DBMS probabilmente implementerà l'archiviazione per il tipo di TESTO in modo identico a varchar (x) in ogni caso. Se non lo fa, e ti interessa davvero, dovresti investigare le strategie di archiviazione interna del tuo particolare sistema e considerare se c'è qualche vantaggio per varchar o no.