Saya akan mengatakan bahwa menambahkan smallint buatan kunci utama akan lebih murah dalam hal ruang penyimpanan, jika tabel dirancang dengan cermat.
Sebuah smallint membutuhkan 2 byte, sedangkan character(10) (yaitu, berlawanan dengan intuisi, sebuah varlena ) yang berisi karakter ASCII, akan menghabiskan 14 byte.
Dalam tabel, 2 byte tambahan akan sia-sia, tetapi jangan lupa bahwa Anda akan memiliki indeks pada kolom kunci utama. Jadi nilai yang diindeks sebenarnya akan disimpan dua kali:sekali di tabel, sekali di indeks.
Demi kesederhanaan, mari kita abaikan header tuple dan overhead lainnya.
-
Menggunakan ISBN sebagai kunci utama akan dikenakan biaya tambahan 14 byte per baris tabel.
-
Menambahkan
smallintkunci utama akan menambahkan dua byte ke tabel dan dua ke indeks, sehingga total empat byte yang ditambahkan.
Jadi menambahkan smallint kunci utama harus menghemat ruang .
Anda tidak boleh mengabaikan masalah penyelarasan. Semua tipe data disimpan di alamat memori yang merupakan kelipatan dari dua kekuatan tertentu. Ini diperlukan oleh arsitektur prosesor. Sebuah smallint biasanya memiliki keselarasan 2, character memiliki keselarasan 1, sedangkan misalnya timestamp memiliki keselarasan 8.
Jadi jika tabel Anda didefinisikan sebagai
CREATE TABLE book (
id smallint PRIMARY KEY,
issue_time timestamp with time zone,
isbn character(10)
);
Maka tabel data akan terlihat seperti ini:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |X|X|X|X|X|X| | | | | | | | | ... (ISBN omitted)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
id padding issue_time
Baris disejajarkan pada batas 8 byte, dan enam byte dari akhir jika id ke awal issue_time akan menjadi “byte padding” kosong.
Jadi untuk memaksimalkannya, Anda harus mempertimbangkan urutan pendefinisian kolom.
Mengapa semua ini tidak terlalu relevan dalam kenyataan:
Tabel dengan 5.000 atau 10.000 entri kecil, apa pun yang terjadi.
Meskipun dihabiskan untuk mengoptimalkan ruang di sini adalah pengoptimalan mikro yang tidak perlu.
Tapi apa yang mungkin menjadi ide cerdas di meja perencanaan dapat dengan mudah menjadi bumerang nanti:Jika – berbeda dari yang Anda harapkan – Anda ingin menyimpan 70.000 buku di meja, Anda akan menemukan bahwa smallint tidak akan cukup, bahkan jika Anda mengizinkan id negatif s. Rasa sakit yang harus Anda tanggung ketika Anda harus mengubah tipe data dari kunci utama dan semua kunci asing yang mereferensikannya dalam sistem langsung akan jauh lebih besar daripada kesenangan yang Anda dapatkan dari menghemat sekitar 100 KB dengan pengoptimalan yang cerdas.
