Tidak seperti beberapa RDBMS lain yang memungkinkan untuk memilih penyandian, SQL Server menyimpan data Unicode hanya dalam UTF-16 (Little Endian), dan data non-Unicode dalam pengkodean 8-bit (ASCII Diperpanjang, DBCS, atau EBCDIC) untuk Halaman Kode apa pun yang tersirat oleh Pengumpulan bidang.
Keputusan mereka untuk memilih UCS-2 cukup masuk akal mengingat UTF-16 diperkenalkan pada pertengahan 1996 dan ditetapkan sepenuhnya pada tahun 2000. Banyak sistem lain juga menggunakan (atau menggunakannya) (silakan lihat:https://en.wikipedia.org/wiki/UTF-16#Usage ). Keputusan mereka untuk melanjutkan dengan itu mungkin lebih dipertanyakan, meskipun mungkin karena Windows dan .NET menjadi UTF-16. Tata letak fisik byte adalah sama antara UCS-2 dan UTF-16, jadi memutakhirkan sistem dari UCS-2 untuk mendukung UTF-16 harus benar-benar berfungsi tanpa perlu mengubah data yang ada.
Tidak. Membuat Jenis Buatan Pengguna khusus melalui SQLCLR adalah tidak , dengan cara apa pun, akan memberi Anda pengganti jenis asli apa pun. Ini sangat berguna untuk membuat sesuatu untuk menangani data khusus. Tetapi string, bahkan dari pengkodean yang berbeda, jauh dari khusus. Mengikuti rute ini untuk data string Anda akan menghancurkan kegunaan sistem Anda, belum lagi kinerja karena Anda tidak akan dapat menggunakan apa pun fungsi string bawaan. Jika Anda dapat menghemat apa pun di ruang disk, keuntungan itu akan terhapus oleh apa yang akan hilang dalam kinerja keseluruhan. Menyimpan UDT dilakukan dengan membuat serialisasi ke VARBINARY . Jadi untuk melakukan apa saja perbandingan string ATAU penyortiran, di luar perbandingan "biner" / "ordinal", Anda harus mengonversi semua nilai lainnya, satu per satu, kembali ke UTF-8 untuk kemudian melakukan perbandingan string yang dapat menjelaskan perbedaan linguistik.
Juga, "dokumentasi" itu benar-benar hanya kode sampel/bukti dari hal-hal konsep. Kode ini ditulis pada tahun 2003 ( http://msftengprodsamples.codeplex.com/SourceControl/latest#Kilimanjaro_Trunk/Programmability/CLR/UTF8String/CS/UTF8String/Utf8String.cs ) untuk SQL Server 2005. Saya melihat skrip untuk menguji fungsionalitas, tetapi tidak ada yang melibatkan kinerja.
Ya, sangat banyak. Secara default, penanganan fungsi bawaan hanya untuk UCS-2. Tetapi mulai di SQL Server 2012, Anda bisa membuat mereka menangani set karakter UTF-16 penuh (baik, pada Versi Unicode 5 atau 6, tergantung pada OS dan versi .NET Framework Anda) dengan menggunakan salah satu susunan yang memiliki nama yang diakhiri dengan _SC (yaitu Karakter Tambahan).
Benar. UTF-16 dan UCS-2 keduanya menggunakan poin kode 2-byte. Tetapi UTF-16 menggunakan beberapa dari mereka secara berpasangan (yaitu Pasangan Pengganti) untuk memetakan karakter tambahan. Poin kode yang digunakan untuk pasangan ini dicadangkan untuk tujuan ini di UCS-2 dan karenanya tidak digunakan untuk memetakan ke simbol apa pun yang dapat digunakan. Inilah sebabnya mengapa Anda dapat menyimpan karakter Unicode apa pun di SQL Server dan karakter itu akan disimpan dan diambil dengan benar.
Benar, meski menyesatkan. Ya, UTF-8 adalah lebar variabel, tetapi UTF-16 juga sedikit variabel karena semua Karakter Tambahan terdiri dari dua titik kode byte ganda. Oleh karena itu UTF-16 menggunakan 2 atau 4 byte per simbol, meskipun UCS-2 selalu 2 byte. Tapi itu bukan bagian yang menyesatkan. Apa yang menyesatkan adalah implikasi bahwa pengkodean Unicode lainnya tidak mampu mengkodekan semua poin kode lainnya. Meskipun UCS-2 dapat menyimpannya tetapi tidak menafsirkannya, baik UTF-16 maupun UTF-32 dapat memetakan semua titik kode Unicode, seperti halnya UTF-8.
Ini mungkin benar, tetapi sama sekali tidak relevan dari perspektif operasional.
Sekali lagi, benar, tetapi sama sekali tidak relevan karena UTF-16 dan UTF-32 juga memetakan semua titik kode Unicode.
Tergantung pada keadaan, ini bisa jadi benar, dan Anda benar untuk khawatir tentang penggunaan yang boros seperti itu. Namun, seperti yang saya sebutkan dalam pertanyaan yang mengarah ke yang ini ( Dukungan UTF-8, SQL Server 2012 dan UTF8String UDT
), Anda memiliki beberapa opsi untuk mengurangi jumlah ruang yang terbuang jika sebagian besar baris dapat masuk ke VARCHAR namun beberapa harus NVARCHAR . Opsi terbaik adalah mengaktifkan KOMPRESI ROW atau KOMPRESI HALAMAN (khusus Editon Perusahaan!). Mulai dari SQL Server 2008 R2, mereka mengizinkan NVARCHAR non-MAX bidang untuk menggunakan "Skema Kompresi Standar untuk Unicode" yang setidaknya sebagus UTF-8, dan dalam beberapa kasus bahkan lebih baik daripada UTF-8. NVARCHAR(MAX) bidang tidak dapat menggunakan kompresi mewah ini , tetapi data IN ROW mereka dapat memperoleh manfaat dari Kompresi ROW dan/atau PAGE biasa. Harap lihat penjelasan berikut untuk kompresi ini dan bagan yang membandingkan ukuran data untuk:UCS-2 / UTF-16 mentah, UTF-8, dan UCS-2 / UTF-16 dengan kompresi data diaktifkan.
SQL Server 2008 R2 - apa itu kompresi UCS2 - Dampak pada sistem SAP
Lihat juga halaman MSDN untuk Kompresi Data untuk detail lebih lanjut karena ada beberapa batasan (selain itu hanya tersedia di Edisi Perusahaan -- TETAPI tersedia untuk semua edisi yang dimulai dengan SQL Server 2016, SP1 !!) dan beberapa keadaan saat kompresi dapat memperburuk keadaan.
Kebenaran pernyataan itu tergantung pada bagaimana seseorang mendefinisikan "disk". Jika Anda berbicara tentang suku cadang komoditas yang dapat Anda beli dari rak di toko untuk digunakan di desktop / laptop Anda, maka tentu saja. Tetapi, jika berbicara dalam hal penyimpanan tingkat perusahaan yang akan digunakan untuk sistem Produksi Anda, maka bersenang-senanglah menjelaskan kepada siapa pun yang mengontrol anggaran bahwa mereka tidak boleh menolak SAN jutaan dolar yang Anda inginkan karena "murah ";-).
Tidak ada yang bisa saya pikirkan. Yah, selama Anda tidak mengikuti saran buruk apa pun untuk melakukan sesuatu seperti mengimplementasikan UDT itu, atau mengonversi semua string menjadi VARBINARY , atau menggunakan NVARCHAR(MAX) untuk semua bidang string;-). Tetapi dari semua hal yang dapat Anda khawatirkan, SQL Server yang menggunakan UCS-2 / UTF-16 seharusnya tidak menjadi salah satunya.
Namun, jika karena alasan tertentu masalah tidak adanya dukungan asli untuk UTF-8 ini sangat penting, maka Anda mungkin perlu mencari RDBMS lain untuk digunakan yang memungkinkan UTF-8.
PERBARUI 2018-10-02
Meskipun ini bukan opsi yang layak, SQL Server 2019 memperkenalkan dukungan asli untuk UTF-8 di VARCHAR / CHAR tipe data. Saat ini ada terlalu banyak bug untuk digunakan, tetapi jika sudah diperbaiki, maka ini adalah opsi untuk beberapa skenario. Silakan lihat posting saya, "Dukungan UTF-8 Asli di SQL Server 2019:Juruselamat atau Nabi Palsu?
", untuk analisis mendetail tentang fitur baru ini.
