Apakah SQLite akan kurang bermanfaat tanpa menerima sisipan nilai-nilai non-numerik ke dalam kolom numerik?

Dalam SQLite pernyataan berikut akan berhasil dan string akan dimasukkan / diperbarui ke dalam SALARYkolom yang bertipe INTEGER:

update employee set salary='TOO MUCH' where emp_id=1;

Perhatikan bahwa nol tidak akan dimasukkan / diperbarui tetapi string "TERLALU JAUH" yang sebenarnya , jadi ini bukan tentang konversi jenis automatis.

FAQ menyatakan:

Ini adalah fitur , bukan bug. SQLite menggunakan pengetikan dinamis. Itu tidak menegakkan batasan tipe data. Data jenis apa pun dapat (biasanya) dimasukkan ke dalam kolom apa pun. Anda dapat menempatkan string panjang acak ke dalam kolom integer, angka floating point di kolom boolean, atau tanggal di kolom karakter. Tipe data yang Anda tetapkan untuk kolom dalam perintah CREATE TABLE tidak membatasi data apa yang dapat dimasukkan ke dalam kolom itu. Setiap kolom dapat memiliki string panjang acak. (Ada satu pengecualian: Kolom tipe INTEGER PRIMARY KEY hanya dapat menampung bilangan bulat bertanda 64-bit. Kesalahan akan terjadi jika Anda mencoba memasukkan apa pun selain bilangan bulat ke dalam kolom INTEGER PRIMARY KEY kolom.)

Jadi perilaku ini jelas disengaja, namun saya bertanya - tanya mengapa SQLite memiliki perilaku ini, karena sebagian besar database SQL lain yang saya tahu berperilaku sangat berbeda, mereka akan menimbulkan kesalahan, atau mengonversi string 0, ketika mencoba memasukkan string non-numerik ke dalam kolom angka

• Apakah perpustakaan SQLite menjadi kurang bermanfaat tanpa perilaku ini?

• Apakah ini dibuat dengan desain agar perpustakaan tetap kecil dan cepat?

• Apakah pustaka SQLite secara signifikan lebih lambat atau lebih besar untuk menimbulkan kesalahan ketika mencoba memasukkan string ke dalam kolom numerik?

Tidak, pengetikan dinamis membutuhkan lebih banyak ruang penyimpanan dan lebih banyak waktu pemrosesan, terutama karena mereka juga menambah afinitas jenis, artinya memiliki jenis yang disukai yang tidak dapat diabaikan oleh pemrogram. Ini benar-benar fitur yang disengaja dengan biaya trade off nyata. Biaya-biaya tersebut secara efektif diabaikan untuk kasus penggunaan target SQLite, tetapi mereka masih ada.

Kegunaan fitur-fitur tersebut sulit dilihat karena Anda tidak terbiasa menyediakannya untuk Anda. Solusi untuk kekurangannya terasa lebih alami bagi Anda sekarang. Karena pengalaman Anda sebelumnya, Anda menganggapnya sebagai bidang INTEGER yang tidak akan pernah menjadi apa pun, tetapi SQLite melihatnya lebih sebagai bidang jenis apa pun, tetapi mungkin sebagian besar berisi bilangan bulat. Mungkin itu adalah kode ZIP untuk perusahaan yang sebagian besar melakukan bisnis di AS, tetapi memiliki beberapa pelanggan Kanada. Mengizinkan pengguna untuk menentukan afinitas integer akan menghemat banyak ruang untuk menjadikannya string di setiap baris, tetapi tetap memberi Anda opsi itu.