Jika Anda memiliki sesuatu yang dekat dengan pilihan, gunakan set karakter Unicode untuk seluruh database. Hidup secara umum sangat mudah seperti itu.
- Ada banyak utilitas dan perpustakaan pihak ketiga yang tidak mendukung kolom NCHAR/ NVARCHAR2 atau yang tidak membuat bekerja dengan kolom NCHAR/ NVARCHAR2 menyenangkan. Ini sangat menjengkelkan, misalnya, ketika alat pelaporan baru Anda yang mengkilap tidak dapat melaporkan data NVARCHAR2 Anda.
- Untuk aplikasi khusus, bekerja dengan kolom NCHAR/ NVARCHAR2 memerlukan lompatan melalui beberapa rintangan yang tidak dapat dilakukan oleh kolom yang dikodekan dengan CHAR/ VARCHAR2 Unicode. Dalam kode JDBC, misalnya, Anda akan terus-menerus memanggil metode Statement.setFormOfUse. Bahasa dan kerangka kerja lain akan memiliki gotcha lain; beberapa akan didokumentasikan dengan baik dan sebagian kecil lainnya akan relatif tidak jelas.
- Banyak paket bawaan hanya akan menerima (atau mengembalikan) VARCHAR2 daripada NVARCHAR2. Anda masih dapat memanggil mereka karena konversi implisit, tetapi Anda mungkin akan mengalami masalah konversi kumpulan karakter.
- Secara umum, dapat menghindari masalah konversi kumpulan karakter dalam database dan memindahkan masalah tersebut ke tepi tempat database sebenarnya mengirim atau menerima data dari klien membuat pekerjaan mengembangkan aplikasi menjadi lebih mudah. Sudah cukup untuk men-debug masalah konversi kumpulan karakter yang dihasilkan dari transmisi jaringan-- mencari tahu bahwa beberapa data rusak ketika prosedur tersimpan menggabungkan data dari VARCHAR2 dan NVARCHAR2 dan menyimpan hasilnya dalam VARCHAR2 sebelum dikirim melalui jaringan dapat menyiksa.
Oracle merancang tipe data NCHAR/ NVARCHAR2 untuk kasus-kasus di mana Anda mencoba untuk mendukung aplikasi lama yang tidak mendukung Unicode dalam database yang sama dengan aplikasi baru yang menggunakan Unicode dan untuk kasus-kasus di mana bermanfaat untuk menyimpan beberapa data Unicode dengan yang berbeda pengkodean (yaitu Anda memiliki sejumlah besar data Jepang yang Anda lebih suka untuk menyimpan menggunakan pengkodean UTF-16 dalam NVARCHAR2 daripada pengkodean UTF-8). Jika Anda tidak berada dalam salah satu dari dua situasi tersebut, dan sepertinya tidak demikian, saya akan menghindari NCHAR/ NVARCHAR2 dengan cara apa pun.
Menanggapi tindak lanjut Anda
Aplikasi kami biasanya sendirian di database Oracle dan menangani data itu sendiri. Perangkat lunak lain yang terhubung ke database terbatas pada pengembang Toad, Tora, atau SQL.
Apa maksudmu "mengurus data itu sendiri"? Saya harap Anda tidak mengatakan bahwa Anda telah mengonfigurasi aplikasi Anda untuk melewati rutinitas konversi kumpulan karakter Oracle dan bahwa Anda melakukan semua konversi kumpulan karakter sendiri.
Saya juga berasumsi bahwa Anda menggunakan semacam API/perpustakaan untuk mengakses database meskipun itu OCI. Sudahkah Anda melihat perubahan apa yang perlu Anda buat pada aplikasi Anda untuk mendukung NCHAR/ NVARCHAR2 dan apakah API yang Anda gunakan mendukung NCHAR/ NVARCHAR2? Fakta bahwa Anda mendapatkan data Unicode di C++ sebenarnya tidak menunjukkan bahwa Anda tidak perlu membuat (berpotensi signifikan) perubahan untuk mendukung kolom NCHAR/ NVARCHAR2.
Kami juga menggunakan SQL*Loader dan SQL*Plus untuk berkomunikasi dengan database untuk pernyataan dasar atau untuk mengupgrade antarversi produk. Kami belum pernah mendengar adanya masalah khusus dengan semua perangkat lunak tersebut terkait NVARCHAR2.
Semua aplikasi tersebut bekerja dengan NCHAR/ NVARCHAR2. NCHAR/ NVARCHAR2 memperkenalkan beberapa kerumitan tambahan ke dalam skrip terutama jika Anda mencoba untuk mengkodekan konstanta string yang tidak dapat direpresentasikan dalam kumpulan karakter basis data. Namun, Anda pasti dapat mengatasi masalah tersebut.
Kami juga tidak mengetahui bahwa administrator basis data di antara pelanggan kami ingin menggunakan alat lain di basis data yang tidak dapat mendukung data di NVARCHAR2 dan kami tidak terlalu peduli apakah alat mereka mungkin terganggu, lagipula mereka ahli dalam pekerjaan mereka dan mungkin menemukan alat lain jika diperlukan.
Meskipun saya yakin bahwa pelanggan Anda dapat menemukan cara alternatif untuk bekerja dengan data Anda, jika aplikasi Anda tidak berfungsi dengan baik dengan alat pelaporan perusahaan mereka atau alat ETL perusahaan mereka atau alat desktop apa pun yang mereka alami, kemungkinan besar bahwa pelanggan akan menyalahkan aplikasi Anda daripada alat mereka. Ini mungkin tidak akan menjadi penghenti pertunjukan, tetapi juga tidak ada gunanya membuat pelanggan bersedih secara tidak perlu. Hal itu mungkin tidak mendorong mereka untuk menggunakan produk pesaing, tetapi tidak akan membuat mereka bersemangat untuk menerima produk Anda.
Bisakah kita juga mengharapkan kerusakan kinerja jika aplikasi kita (yang dikompilasi di bawah Visual C++), yang menggunakanwchar_t untuk menyimpan UTF-16, telah melakukan konversi penyandian pada semua data yang diproses?
Saya tidak yakin apa "konversi" yang Anda bicarakan. Ini mungkin kembali ke pertanyaan awal saya tentang apakah Anda menyatakan bahwa Anda melewati lapisan NLS Oracle untuk melakukan konversi set karakter sendiri.
Intinya, saya tidak melihat keuntungan menggunakan NCHAR/NVARCHAR2 mengingat apa yang Anda gambarkan. Ada banyak potensi kerugian untuk menggunakannya. Bahkan jika Anda dapat menghilangkan 99% dari kerugian yang tidak relevan dengan kebutuhan khusus Anda, Anda masih menghadapi situasi di mana yang terbaik adalah mencuci antara dua pendekatan. Karena itu, saya lebih suka menggunakan pendekatan yang memaksimalkan fleksibilitas ke depan, dan itu mengubah seluruh database menjadi Unicode (mungkin AL32UTF8) dan hanya menggunakannya.
