Apakah ada alasan untuk menggunakan ukuran VARCHAR dibulatkan ke offset 128/256/4096 byte?

Dalam skema database, saya sering melihat ukuran VARCHAR dibulatkan ke byte byte 128/256 atau 4096. Saya sudah pernah melakukannya sebelumnya, dan ide di baliknya mungkin sesuatu dengan efisiensi.

Namun, apakah masih ada alasan yang sah untuk melakukannya saat ini? Saya sering menggunakan '50', '100' atau '200' sebagai ukuran VARCHAR hari ini, karena mereka lebih alami dan biasanya juga ditampilkan dalam pemeriksaan validasi kepada pengguna.

Satu-satunya penjelasan rasional yang dapat saya pikirkan adalah: Jika DBMS menyimpan nilai kolom secara berurutan, dan ukurannya tidak dibulatkan menjadi kekuatan 2, maka beberapa elemen mungkin harus "dipecah" menjadi dua halaman pada hard drive (mis. 10 byte pertama di halaman n dan 40 byte berikutnya di halaman n +1), yang dalam beberapa kasus dapat menyebabkan dua pembacaan dari hard drive alih-alih satu.

Lebih mungkin adalah titik @Jan Hudec bahwa, banyak programmer menganggap "128" atau "256" sebagai "angka bulat yang bagus", yang menjadikannya pilihan yang lebih alami daripada angka ganjil seperti 137, 19 atau 100.

Secara umum tidak ada alasan untuk panjang kolom tersebut. Tidak akan ada peningkatan kinerja kolom varchar (100) versus kolom varchar (128).

Namun, saya akan memeriksa sistem database yang Anda gunakan untuk klarifikasi lebih lanjut tentang pembatasan dan peringatan khusus vendor lainnya.

Sebagai contoh, berikut adalah contoh pembatasan sistem database untuk SQL Server:

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

Panjang total baris lebih penting daripada panjang kolom individual.

Saya tidak ingat apakah itu DBMS atau kompiler, tapi saya ingat (dulu) belajar menggunakan kekuatan 2 untuk panjang array dan kolom. Ada justifikasi bahwa itu 'lebih cepat' karena implementasinya bisa menggunakan bit shifting. Apakah benar lagi adalah pertanyaan terbuka. Adakah yang tahu apakah masih valid?

BTW Saya sudah pindah lebar kolom ke nomor seragam b / c itu aneh untuk memberitahu pengguna batas char adalah 256 karakter.

Dan beberapa database yang sangat lama memang membatasi Anda untuk 256 kolom char-width.

Mungkin tidak terlalu penting, karena Anda hanya akan melihat efisiensi penyimpanan jika ukuran seluruh baris Anda adalah kekuatan 2. Mungkin saja, tetap dengan kekuatan 2 dapat menjadikannya lebih mungkin dibandingkan ukuran baris Anda. akan bekerja dengan kekuatan dua (karena kebanyakan tipe data asli cenderung berukuran 2 [tergantung pada database]), tapi saya tidak akan membuatnya menjadi aturan yang sulit dan cepat.

Mungkin lebih masuk akal jika Anda bekerja dengan kolom besar (4K atau lebih besar), karena itu mungkin dapat disimpan secara terpisah, dan mengukurnya sehingga sesuai dalam satu blok penyimpanan (apa pun yang digunakan database Anda untuk penyimpanan di-disk) akan mendapatkan kamu sesuatu.

Meskipun saya tidak terbiasa dengan semua sistem DBMS, unit penyimpanan "fisik" terkecil di Oracle adalah "blok" yang secara default berukuran 2KB. Praktek menentukan ukuran kolom Anda dalam kekuatan dua adalah bagian dari praktik yang lebih besar mengukur ukuran baris Anda agar sesuai dengan benar dalam blok penyimpanan. Mengubah ukuran kolom Anda sehingga satu baris akan membutuhkan satu byte lebih dari ukuran blok akan membutuhkan dua blok untuk dialokasikan dan baris Anda juga akan span dua blok, membuat membaca, menyisipkan dan memindai lebih memakan waktu daripada jika Anda bisa memasukkan setiap baris satu blok (dan hanya memiliki satu baris di setiap blok). Setidaknya, itulah alasan historisnya. Saat ini, kebanyakan orang menganggap praktik ini sebagai sub-optimasi.