C'è qualche motivo per usare le dimensioni VARCHAR arrotondate a un offset di 128/256/4096 byte?

Negli schemi di 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 era probabilmente qualcosa di efficiente.

Tuttavia, c'è ancora un motivo valido per farlo al giorno d'oggi? Oggi uso spesso '50', '100' o '200' come dimensioni di VARCHAR, in quanto sono più naturali e in genere mostrate anche nei controlli di convalida all'utente.

L'unica spiegazione razionale a cui riesco a pensare sarebbe: se il DBMS memorizza i valori di una colonna in sequenza e le dimensioni non sono arrotondate a una potenza di 2, alcuni elementi potrebbero dover essere "divisi" in due pagine sul disco rigido unità (ad esempio i primi 10 byte nella pagina n e i successivi 40 byte nella pagina n + 1), che in alcuni casi potrebbe portare a due letture dal disco rigido anziché a uno.

Più probabilmente è il punto di @Jan Hudec che molti programmatori considerano "128" o "256" come "bei numeri rotondi", il che li rende una scelta più naturale di numeri dispari come 137, 19 o 100.

In generale non vi è alcun motivo per quelle 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 si sta utilizzando per ulteriori chiarimenti sulle restrizioni e altri avvertimenti specifici del fornitore.

Ad esempio, ecco un buon esempio di limitazione del sistema di database per SQL Server:

http://msdn.microsoft.com/en-us/library/ms186981.aspx

La lunghezza totale della riga è più importante della lunghezza delle singole colonne.

Non ricordo se fosse un DBMS o un compilatore, ma ricordo (molto tempo fa) di aver imparato a usare potenze di 2 per lunghezze di array e colonne. C'era una giustificazione che era "più veloce" perché l'implementazione poteva usare lo spostamento dei bit. Se è più vero è una domanda aperta. Qualcuno ha qualche idea sul fatto che sia ancora valido?

A proposito, ho spostato le larghezze delle colonne in numero uniforme b / c, è strano dire agli utenti che il limite di caratteri è di 256 caratteri.

E alcuni database molto vecchi ti limitavano a 256 colonne di larghezza caratteri.

Probabilmente non ha molta importanza, dal momento che vedresti una certa efficienza di archiviazione solo se la dimensione dell'intera riga fosse una potenza di 2. È possibile che restare con potenze di 2 potrebbe rendere più probabile la dimensione della tua fila funzionerebbe a una potenza di due (dal momento che la maggior parte dei tipi di dati nativi tendono ad avere una potenza di 2 dimensioni (a seconda del database)), ma non la renderei una regola rigida.

Potrebbe avere più senso se si lavorasse con colonne di grandi dimensioni (4K o più grandi), dal momento che queste potrebbero essere archiviate separatamente e dimensionarle in modo da adattarle a un blocco di archiviazione (qualunque cosa il database utilizzi per l'archiviazione su disco) otterrebbe tu qualcosa.

Sebbene non conosca tutti i sistemi DBMS, la più piccola unità di archiviazione "fisica" in Oracle è un "blocco" che per impostazione predefinita ha una dimensione di 2 KB. La pratica di dimensionare le colonne in potenze di due fa parte di una pratica più ampia di dimensionare le righe per adattarle correttamente ai blocchi di archiviazione. Ridimensionare le colonne in modo che una riga richiederebbe un byte in più rispetto alla dimensione del blocco richiederebbe l'assegnazione di due blocchi e la riga si estenderebbe anche su due blocchi, rendendo la lettura, l'inserimento e la scansione più dispendiosi in termini di tempo rispetto a se si potesse adattare ogni riga a un blocco (e ha solo una riga in ciascun blocco). Questo, almeno, è il motivo storico per questo. Al giorno d'oggi, la maggior parte delle persone considera questa pratica come subottimizzazione.