Mengapa masih ada tipe data varchar?

Banyak basis data saya memiliki bidang yang didefinisikan sebagai varchars. Ini tidak banyak masalah sejak saya tinggal dan bekerja di Amerika (di mana satu-satunya bahasa yang ada adalah "Amerika". Ahem )

Setelah bekerja dengan basis data selama sekitar 5 tahun, saya akhirnya menemukan saya mengalami masalah dengan sifat terbatas bidang varchar dan saya harus memodifikasi bidang saya untuk menyimpan data sebagai nvarchars. Setelah harus membuat pembaruan lain ke tabel, mengubah bidang varchar ke nvarchar, saya baru saja berpikir - mengapa kita masih melakukannya dengan cara ini? Saya sudah sejak lama membuat keputusan mental untuk mendefinisikan semua bidang teks baru saya menjadi nvarchar, bukan varchar, yang merupakan apa yang saya pelajari dari buku teks ketika saya berada di sekolah 10 tahun yang lalu.

Ini tahun 2011 dan ada rilis baru SQL Server tahun lalu. Mengapa kita terus mendukung tipe data varchar ketika kita dapat / seharusnya menggunakan nvarchar?

Saya tahu bahwa sering diperdebatkan bahwa nvarchars "dua kali lebih besar" dari varchars, jadi penggunaan ruang penyimpanan bisa menjadi salah satu argumen untuk mempertahankan varcars.

Namun, pengguna saat ini dapat mendefinisikan nvarchars mereka untuk menyimpan data sebagai UTF-8, bukan UTF-16 default jika mereka ingin menghemat ruang penyimpanan. Ini akan memungkinkan untuk pengkodean 8-bit jika itu terutama diinginkan, sambil memberikan jaminan bahwa karakter langka 2-8 byte yang dimasukkan ke dalam DB mereka tidak akan merusak apa pun.

Apakah saya melewatkan sesuatu? Apakah ada alasan bagus mengapa ini tidak berubah selama 15-20 tahun terakhir?

1. pekerjaan varchar cukup baik untuk banyak bahasa Eropa Barat (Norwegia, Denmark, Jerman, Perancis, Belanda dll juga) tunduk pada beberapa masalah pengumpulan

2. Lihat ini pada kinerja SO varchar vs nvarchar nvarchar memiliki implikasi kinerja yang serius

3. Ini sepele dibandingkan dengan berurusan dengan tanggal MDY vs DMY

Selain jawaban yang membahas standar dan kompatibilitas, orang juga harus mengingat kinerja. Sementara ruang disk mudah diterima sebagai murah, DBA / Pengembang sering mengabaikan fakta bahwa kinerja permintaan terkadang berhubungan langsung dengan baris / ukuran halaman tabel. Menggunakan NVARCHARdaripada VARCHAR(bila tidak perlu) akan secara efektif menggandakan ukuran baris untuk bidang karakter Anda. Jika Anda memiliki, katakanlah, 5 atau 10 bidang yang panjangnya 50, Anda sedang berbicara tentang kemungkinan menambahkan 500 byte tambahan per baris. Jika Anda memiliki tabel lebar, ini bisa mendorong setiap baris ke beberapa halaman dan berdampak buruk pada kinerja.

Banyak organisasi yang masih memiliki basis aplikasi, antarmuka, platform, dan alat yang banyak diinstal yang menggunakan karakter byte tunggal. Database jarang hidup dalam isolasi - mereka adalah salah satu bagian dari ekosistem IT. Jika Anda memiliki ribuan komponen dan jutaan baris kode yang tergantung pada karakter byte tunggal, maka Anda perlu alasan yang baik untuk menginvestasikan waktu dan uang yang diperlukan untuk beralih ke unicode. Perubahan pada skala itu bisa memakan waktu bertahun-tahun untuk diselesaikan. Di beberapa tempat Unicode masih relatif baru, jarang atau tidak didukung sepenuhnya.

VARCHAR dan NVARCHAR adalah bagian dari ISO Standard SQL. Menghapus atau mencabut dukungan VARCHAR di SQL Server akan menjadi langkah mundur dalam kompatibilitas dan portabilitas.

Atau, pengguna saat ini dapat mendefinisikan nvarchars mereka untuk menyimpan data sebagai UTF-8 dan bukan UTF-16 default jika mereka ingin menghemat ruang penyimpanan.

Inilah yang dilakukan oleh kebanyakan database open-source VARCHAR.

• MySQL menyediakan utf8dan ucs2"mengoleksi".
• SQLite memberi Anda pilihan antara UTF-8 (default) dan UTF-16.
• PostgreSQL mendukung UTF-8 (tetapi tidak UTF-16).

Tidak perlu memiliki dua tipe string yang terpisah.

Microsoft adalah yang aneh dengan pandangannya bahwa string 8-bit adalah untuk pengkodean sebelumnya dan Unicode = UTF-16. Yang mungkin terkait dengan Windows API itu sendiri mengobati chardan wchar_tseperti itu.

Karena beberapa dari kita membuat aplikasi yang lebih ringan dan lebih kecil dengan perangkat keras yang tidak memerlukan kemampuan Unicode. Mungkin kita perlu mengubahnya nanti, tetapi untuk sekarang, kita tidak membutuhkannya. Saya suka string saya mengambil 1/2 ruang yang seharusnya mereka miliki di bawah NVARCHAR.