Mengapa menyimpan flag / enum dalam database sebagai string, bukan bilangan bulat?

Saya telah menjelajahi kesedihan SQL dari beberapa CMS yang terkenal, termasuk Drupal 7, Wordpress (beberapa versi yang sangat lama), dan beberapa aplikasi khusus berdasarkan Python.

Semua dump ini berisi data dengan flag string bukan integer. Misalnya, status posting ini diwakili sebagai published, closedatau inheritbukan 1, 2atau 3.

Saya memiliki pengalaman yang sangat terbatas dalam mendesain database dan saya tidak pernah melewati SQL sederhana, tetapi saya selalu diajari bahwa saya harus menggunakan numeric / flag integer untuk data seperti ini. Sudah jelas bahwa tinyintmengkonsumsi jauh lebih sedikit ruang dalam database daripada, misalnya varchar(9),.

Jadi apa yang saya lewatkan? Bukankah ini pemborosan penyimpanan data dan redundansi data? Bukankah menjelajah, mencari, dan mengindeks akan sedikit lebih cepat jika kolom ini menggunakan bilangan bulat bukan string?

— Trejder
sumber

Apakah Anda yakin mereka tidak benar-benar menggunakan dev.mysql.com/doc/refman/5.0/en/enum.html yang akan terlihat seperti string dalam dump. Either way saya pikir hari ini hampir dianggap sebagai optimasi mikro.

— Esben Skov Pedersen

Agak terkait: Cara terbaik untuk menyimpan nilai enum dalam database - String atau Int

— manlio

Pertanyaan ini secara mendasar merupakan daya tarik bagi otoritas.

— DeadMG

Tidak lengkap, jawab, tapi ... Anda tahu bahasa scripting Lua? Terkenal karena langsung dan berkinerja tinggi, terbiasa menulis seluruh mesin game, dll? Cukup mengejutkan ... mereka tidak pernah repot-repot memiliki tipe angka sama sekali. Kode penanganan string mereka sangat efektif, mereka dapat menambahkan angka bersama yang sebenarnya adalah string, dalam kode mesin game peka waktu. Seperti JavaScript, mereka bahkan tidak memiliki objek - hanya tabel hash yang sangat mewah. Pandangan programmer C tentang "sejumlah besar chars? Bagaimana tidak efisien!" sudah ketinggalan zaman dibandingkan dengan 2015.

— Katana314

Diedit untuk menghapus bagian "banding ke otoritas" dan dibuka kembali, karena pertanyaan tentang penggunaan string daripada ints benar-benar sesuai topik, asalkan itu tidak secara khusus tentang "otoritas" itu.

— Ixrec

Jawaban:

Ya, menyimpan string sebagai ganti angka dapat menggunakan lebih banyak ruang. Alasan mengapa profil tinggi melakukannya adalah karena mereka berpikir manfaat dari solusi itu lebih besar daripada biaya.

Apa manfaatnya? Anda dapat dengan mudah membaca dump database dan memahami apa itu tanpa menghafal tabel enum, dan bahkan GUI semi-resmi mungkin hanya menggunakan nilai-nilai themeelves daripada mengubah catatan yang mereka dapatkan. (Ini adalah bentuk dasar ruang disk / pengorbanan waktu pemrosesan.)

Bagaimana dengan biayanya? Kapasitas penyimpanan data belum menjadi hambatan dalam CMS sejak lama, karena disk menjadi begitu besar dan sangat murah. Waktu programmer, di sisi lain, biasanya menjadi lebih mahal - sehingga segala sesuatu yang memperdagangkan upaya pengembangan untuk ruang disk juga merupakan hal yang baik, dari perspektif bisnis.

— Kilian Foth
sumber

Ya, menyimpan barang-barang seperti yesatau trueakan memakan lebih banyak ruang daripada tinyint. Ini seharusnya tidak mengejutkan. Itu juga membuat pengindeksan dan dengan demikian bergabung kurang efisien untuk database. Ini juga memiliki penalti kebingungan yang mungkin untuk apa nilai yang benar ( yesvs y).

Namun, ada banyak pendekatan yang terlihat mirip dengan menyimpan string dalam database (khususnya MySQL) yang efisien.

Pertama, MySQL memiliki enumtipe ( dokumen ) yang dapat terlihat sangat mirip string Boolean atau string terbatas ketika diatur dengan cara itu. Ini juga memberlakukan hanya nilai-nilai valid yang dimasukkan. Ini seringkali jauh lebih berguna daripada menyimpan 1, 2atau 3sebagai nilai karena artinya disampaikan dengan informasi. Enum datang dengan penalti bahwa perubahan skema diperlukan untuk menambah atau menghapus jenis.

Ini membawa kita ke tabel anak dan kunci asing (berlaku untuk semua database). Ya, Anda menyimpan beberapa nilai sebagai kunci (kembali ke 1, 2atau 3) dan nilai published, closeddan inheritdisimpan dalam tabel lain. Dengan menggunakan view ( docs ) maka dimungkinkan untuk membuatnya terlihat seperti tabel yang berisi string daripada kunci. Ini memiliki keuntungan bahwa tidak diperlukan perubahan skema untuk menambah atau menghapus entri dari tabel anak.

Tepatnya bagaimana hal-hal disimpan akan membutuhkan satu untuk melihat DDL sebenarnya dari skema untuk menentukan metode apa yang digunakan dan mendapatkan beberapa petunjuk tentang trade off yang telah mereka pilih.