Negli schemi del database, noto spesso che le dimensioni di VARCHAR sono arrotondate agli offset di byte 128/256 o 4096. L'ho già fatto prima e l'idea alla base di questo era probabilmente qualcosa con efficienza.
Tuttavia, esiste ancora un valido motivo per farlo oggigiorno? Io uso spesso "50", "100" o "200" come dimensioni VARCHAR in questi giorni, in quanto sono più naturali e in genere vengono visualizzati anche nei controlli di convalida all'utente.
L'unica spiegazione razionale che posso pensare sarebbe: Se il DBMS memorizza i valori di una colonna in modo sequenziale e le dimensioni non sono arrotondate a una potenza di 2, allora alcuni elementi potrebbero dover essere "divisi" in due pagine sul disco rigido (ad esempio i primi 10 byte nella pagina n ei successivi 40 byte nella pagina n + 1), che in alcuni casi potrebbero portare a due letture dal disco rigido anziché uno.
Più probabilmente è il punto @Jan Hudec che, molti programmatori pensano a "128" o "256" come "numeri tondi carini", il che li rende una scelta più naturale rispetto a numeri dispari come 137, 19 o 100.
In generale non c'è motivo per queste lunghezze di colonna. Non ci sarà alcun miglioramento delle prestazioni di una colonna varchar (100) rispetto a una colonna varchar (128).
Tuttavia, vorrei ricontrollare il sistema di database che stai utilizzando per ulteriori chiarimenti sulle restrizioni e su altri avvertimenti specifici del venditore.
Ad esempio, ecco un buon esempio di restrizione di sistema del database per SQL Server:
La lunghezza totale della riga è più importante delle singole lunghezze di colonna.
Non ricordo se fosse un DBMS o un compilatore, ma ricordo (molto tempo fa) di imparare a usare le potenze di 2 per le lunghezze di colonne e colonne. C'era una giustificazione che fosse "più veloce" perché l'implementazione poteva usare lo spostamento di bit. Se sia più vero è una domanda aperta. Qualcuno ha qualche idea sul fatto che sia ancora valido?
BTW Ho spostato le larghezze delle colonne al numero uniforme b / c è strano dire agli utenti che il limite del char è di 256 caratteri.
E alcuni database molto vecchi ti hanno limitato a 256 colonne di larghezza di carattere.
Probabilmente non ha molta importanza, dal momento che vedresti solo un po 'di efficienza di storage se la dimensione dell'intera fila fosse una potenza di 2. È possibile che attaccare con i poteri di 2 potrebbe rendere più probabile che la dimensione della tua riga si estenderebbe ad una potenza di due (dal momento che la maggior parte dei tipi di dati nativi tende ad essere power-of-2 [a seconda del database]), ma non lo farei una regola dura e veloce. / p>
Potrebbe avere più senso se si lavorasse con colonne grandi (4K o più grandi), dal momento che potrebbero essere memorizzate separatamente e ridimensionarle in modo che si adattino all'interno di un blocco di memorizzazione (qualunque sia il database utilizzato per l'archiviazione su disco ) ti avrebbe guadagnato qualcosa.
Anche se non ho familiarità con tutti i sistemi DBMS, la più piccola unità di archiviazione "fisica" in Oracle è un "blocco" che per impostazione predefinita è di 2 KB. La pratica di dimensionare le colonne in due è parte di una pratica più ampia di dimensionamento delle righe per adattarsi correttamente nei blocchi di memoria. Dimensionando le tue colonne in modo che una riga richieda un byte in più rispetto alla dimensione del blocco richiederebbero due blocchi da allocare e la tua riga si estenderà anche su due blocchi, rendendo la lettura, l'inserimento e la scansione più dispendiosi di tempo rispetto al caso in cui si possa adattare ogni riga a un blocco (e ha solo una riga in ogni blocco). Questo, almeno, è la ragione storica per questo. Oggigiorno, molte persone considerano questa pratica come sub-ottimizzazione.
Leggi altre domande sui tag database database-design